__report_bad_irq kernel lockups

[Yhg1s]

I have a single Asus EN7600GT PCI-X card, actively cooled, in an Asus P5N32-SLI motherboard (nForce4 SLI (for Intel) chipset) with a Pentium-D 3.0Ghz. I'm running i386-linux (although the CPU is EM64T capable), and every now and then, when running OpenGL applications, my system logs the following message, and locks up:

[<c01347f4>] __report_bad_irq+0x24/0x7f
[<c01348cc>] note_interrupt+0x7d/0x241
[<f9346329>] nv_kern_isr+0x2f/0x62 [nvidia]
[<c01342dd>] handle_IRQ_event+0x2e/0x5a
[<c01343da>] __do_IRQ+0xd1/0xe7
[<c0104dc1>] do_IRQ+0x19/0x24
[<c0103516>] common_interrupt+0x1a/0x20

The system isn't quite dead when it locks up; I can still use the magic SysRq key to kill all processes, and a few seconds later there is single update of my X screens to show that things are terminated, and I can also use magic SysRq to sync, unmount and reboot. Simply waiting, before or after killing all processes, doesn't do anything. I have tried kernels 2.6.15 through 2.6.18pre2, where 2.6.16.26/27 seem most stable (but it's hard to tell.) All kernels were running the latest Linux NVIDIA drivers, 8762, for i386. Compiling for UP or SMP, or with or without hyperthreading, or with or without kernel pre-emption, or enabling or disabling kernel IRQ loadbalancing, or cycling the pre-emption model through the available types, all don't seem to matter. Booting with 'pci=routeirq' or 'pci=conf1', which has been suggested in similar __report_bad_irq instances, doesn't matter either. I'm running X.org 7.0 (from debian unstable), on two analog screens connected through VGA-to-DVI dongles. It doesn't matter whether I run them in TwinView, dual-head or single-screen mode, nor whether I disconnect one of the monitors. The PCI-X card is on an interrupt of its own, unshared with other hardware, according to /proc/interrupts.

The system is adequately cooled, the temperatures of the CPU, motherboard and the card itself (according to nvidia-settings) never going higher than, respectively, 50 degrees, 45 degrees and 58 degrees (with 54 degrees being the non-3D operating speed).I haven't had any other stability problems, but I haven't been able to test with another PCI-X card. I was hoping someone had a suggestion for me to try, because I'm fresh out of ideas :-)

[netllama]

Please generate and post an nvidia-bug-report.log, however this sounds like a BIOS bug.

Thanks,
Lonni

[Yhg1s]

nvidia-bug-report.log attached. I'm running the latest beta AMIBIOS provided by Asus for this board (403.) I had the same issues when I ran the latest non-beta AMIBIOS (310), too.

[netllama]

This looks likely as the root of the problem (from dmesg):
pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS

I'd suggest reporting that to Asus.

I have a few questions:
0) Where did you obtain the kernel that you're using?
1) Does this problem also reproduce with an official Debian kernel?

Thanks,
Lonni

[Yhg1s]

Originally Posted by netllama

0) Where did you obtain the kernel that you're using?

Built it myself, from stock kernel source. No additional patches, just the nvidia kernel module.

Originally Posted by netllama

1) Does this problem also reproduce with an official Debian kernel?

The lockup happens with official Debian kernel images (for 2.6.16) too, yes. I'll have to wait until I can safely reboot to see if it also reports the same message, though.

[Yhg1s]

Originally Posted by netllama

1) Does this problem also reproduce with an official Debian kernel?

Yes, the crash as well as the message:

pcie_portdrv_probe->Dev[007e:10de] has invalid IRQ. Check vendor BIOS

happen using the official debian 2.6.16-686-smp kernel as well.

I'll be contacting ASUS.