Hi,

New install Suse 9.2, I need info on managing IRQ channels, I think. It seems that both the ethernet card driver (e100) and the uhci_hcd driver (both kernel modules) are attempting to use IRQ 9. procinfo shows uhci_hcd on IRQ 9 and the YaST hardware info shows the card using IRQ 9 as a resource. There is a four port usb hub on the relevant usb port. What happens is that in the (about 20 minute) absence of any open connections or running network apps, the kernel shuts down IRQ 9. After this nothing I do with ifconfig or its relations can bring the connection back up, but a reboot does. I'm not sure what is going on, but I'm pretty sure that not disabling the interrupt request channel would solve it. How can I tell the kernel to stop doing this? Below is the log info.

Jan 2 12:23:23 linux su: (to nobody) root on none
Jan 2 12:23:23 linux su: pam_unix2: session started for user nobody, service su
Jan 2 12:24:08 linux kernel: irq 9: nobody cared!
Jan 2 12:24:08 linux kernel: [<c010868c>] __report_bad_irq+0x1c/0x70
Jan 2 12:24:08 linux kernel: [<c010875b>] note_interrupt+0x5b/0x80
Jan 2 12:24:08 linux kernel: [<c010894c>] do_IRQ+0xdc/0x120
Jan 2 12:24:08 linux kernel: [<c0106cd8>] common_interrupt+0x18/0x20
Jan 2 12:24:08 linux kernel: [<c01205f1>] __do_softirq+0x31/0xa0
Jan 2 12:24:08 linux kernel: [<c0120686>] do_softirq+0x26/0x30
Jan 2 12:24:08 linux kernel: [<c0108955>] do_IRQ+0xe5/0x120
Jan 2 12:24:08 linux kernel: [<c0106cd8>] common_interrupt+0x18/0x20
Jan 2 12:24:08 linux kernel: [<c0139621>] bad_range+0x1/0x50
Jan 2 12:24:08 linux kernel: [<c013a14c>] buffered_rmqueue+0x9c/0x1d0
Jan 2 12:24:08 linux kernel: [<c013a3a3>] __alloc_pages+0x123/0x3b0
Jan 2 12:24:08 linux kernel: [<c013a648>] __get_free_pages+0x18/0x30
Jan 2 12:24:08 linux kernel: [<c01611d3>] __pollwait+0x63/0xa0
Jan 2 12:24:08 linux kernel: [<c02e9ee2>] unix_poll+0x12/0x80
Jan 2 12:24:08 linux kernel: [<c028cd82>] sock_poll+0x12/0x20
Jan 2 12:24:08 linux kernel: [<c01614b4>] do_select+0x1b4/0x300
Jan 2 12:24:08 linux kernel: [<c0161170>] __pollwait+0x0/0xa0
Jan 2 12:24:08 linux kernel: [<c0161918>] sys_select+0x2f8/0x4d0
Jan 2 12:24:08 linux kernel: [<c011fe95>] sys_gettimeofday+0x25/0x60
Jan 2 12:24:08 linux kernel: [<c0105c69>] sysenter_past_esp+0x52/0x79
Jan 2 12:24:08 linux kernel: handlers:
Jan 2 12:24:08 linux kernel: [<e10d4aa0>] (usb_hcd_irq+0x0/0x50 [usbcore])
Jan 2 12:24:08 linux kernel: [<e10d4aa0>] (usb_hcd_irq+0x0/0x50 [usbcore])
Jan 2 12:24:08 linux kernel: [<e084f430>] (e100_intr+0x0/0x110 [e100])
Jan 2 12:24:08 linux kernel: [<e1377120>] (snd_emu10k1_interrupt+0x0/0x350 [snd_emu10k1])
Jan 2 12:24:08 linux kernel: Disabling IRQ #9

Thanks

Well, I'm not sure I'd call this a solution, but it seems to have solved the problem nonetheless. Evidently this has been a problem with (probably) older hardware since at least SuSE 9.0. I found a few solutions, with results for me:

1. Send noirqdebug at the boot prompt (e.g. in lilo append statement). This made things worse for me, causing a windowsesque freeze very shortly after booting, and more boot trouble thereafter, but it seems to have worked for others.

2. Fiddle with e100 module option. For example IntDelay allows modification of time units between which the adapter will generate interrupts. However, although YaST allows one to enter commands in the "options" box of card configuration, the kernel doesn't actually recognize them when communicated this way, just "unknown option." In theory http://www.intel.com/support/network...linux/e100.htm is how it works.

3. Disable or modify ACPI or APM settings. This seems to be in fact where the problem starts. Even disabling an unnecessary powersaved (for laptops, which I'm not on) that was running by default (or at least without asking) didn't quite do it for me though. dmesg tells me this:
ACPI disabled because your bios is from 2000 and too old
and later
ACPI: IRQ9 SCI: Edge set to Level Trigger. (even after option 4, which I interpret as ACPI hard coded for something it can't have, and possibly denies itself anyway)

4. Transcend and disallow use of IRQ9 in BIOS setup. This seemed extreme, but a week's worth of random disabling led me to it. Oddly enough, reserving IRQ9 seems to have fixed it. Now all the devices/controllers (two instances of uhci_hcd, e100, and emu10k1) that were using IRQ9 are now using IRQ5, and no one is complaining. I have to admit I'm a little afraid to shut down, but a benefit of linux is that I don't have to for months at least.

5. Wait for a patch. Reasonably the older your hardware gets the less you can expect support, so I'm not sure this is much of an option. However, it seems to be a recognized bug that has been resolved at the kernel level in the past.

Thank you for posting what you found. I don't have your problem right now, but I appreciate the extra time you spent to come back and report your solution. Too few people do this. It's one of the ways the LQ community can improve.