From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041212 Firefox/1.0 Description of problem: Running fedora-core current (at present kernel 2.6.9-FC4_1014 but all recent (since mid-aug 2004) development kernels) I'm having problems with the kernel de-registering interrupts. The order is always the same - first USB goes, then (after a few hours) ethernet. The following is logged in /var/log/messages for the USB interrupts Dec 11 15:06:35 bessie kernel: irq 11: nobody cared! (screaming interrupt?) Dec 11 15:06:35 bessie kernel: irq 11: Please try booting with acpi=off and report a bug Dec 11 15:06:35 bessie kernel: [<c0107316>] __report_bad_irq+0x3a/0x77 Dec 11 15:06:35 bessie kernel: [<c010758d>] note_interrupt+0xea/0x115 Dec 11 15:06:35 bessie kernel: [<c01077cb>] do_IRQ+0xd5/0x130 Dec 11 15:06:35 bessie kernel: [<c02c7d14>] common_interrupt+0x18/0x20 Dec 11 15:06:35 bessie kernel: [<c0104018>] default_idle+0x0/0x2c Dec 11 15:06:35 bessie kernel: [<c02c007b>] unix_release_sock+0x162/0x201 Dec 11 15:06:35 bessie kernel: [<c0104041>] default_idle+0x29/0x2c Dec 11 15:06:35 bessie kernel: [<c010409d>] cpu_idle+0x26/0x3b Dec 11 15:06:35 bessie kernel: handlers: Dec 11 15:06:35 bessie kernel: [<c024e310>] (usb_hcd_irq+0x0/0x4b) Dec 11 15:06:35 bessie kernel: [<c024e310>] (usb_hcd_irq+0x0/0x4b) Dec 11 15:06:35 bessie kernel: Disabling IRQ #11 And the following when the ethernet gets disabled Dec 11 23:08:40 bessie kernel: irq 185: nobody cared! (screaming interrupt?) Dec 11 23:08:40 bessie kernel: irq 185: Please try booting with acpi=off and report a bug Dec 11 23:08:40 bessie kernel: [<c0107316>] __report_bad_irq+0x3a/0x77 Dec 11 23:08:40 bessie kernel: [<c010758d>] note_interrupt+0xea/0x115 Dec 11 23:08:40 bessie kernel: [<c01077cb>] do_IRQ+0xd5/0x130 Dec 11 23:08:40 bessie kernel: [<c02c7d14>] common_interrupt+0x18/0x20 Dec 11 23:08:40 bessie kernel: handlers: Dec 11 23:08:40 bessie kernel: [<e08ef8c5>] (rtl8139_interrupt+0x0/0x17d [8139too]) Dec 11 23:08:40 bessie kernel: Disabling IRQ #185 Once the ethernet interrupt has gone the machine is effectively dead as it has quite a bit NFS mounted. unloading and reloading the ethernet driver just results in the "nobody cared"..."Disabling IRQ" message being issued immediately. Booting with acpi=off does appear to fix the problem - so, as requested, I'm reporting a bug. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1) install Fedora development on an abit-vp6 2) wait :) Actual Results: Errors as above Additional info:
any better with the latest errata ?
Just the same $ uname -a Linux bessie.flinders.org 2.6.10-1.1154_FC4smp #1 SMP Fri Feb 25 19:41:11 EST 2005 i686 i686 i386 GNU/Linux $ dmesg|tail -20 APIC error on CPU1: 40(40) APIC error on CPU0: 40(40) APIC error on CPU0: 40(40) APIC error on CPU1: 40(40) APIC error on CPU1: 40(40) APIC error on CPU1: 40(40) irq 11: nobody cared! [<c0138207>] __report_bad_irq+0x2b/0x68 [<c01382a0>] note_interrupt+0x43/0x67 [<c0137dd6>] __do_IRQ+0xe5/0x117 [<c0105d16>] do_IRQ+0x62/0x7e ======================= [<c01046f6>] common_interrupt+0x1a/0x20 [<c0102018>] default_idle+0x0/0x29 [<c010203b>] default_idle+0x23/0x29 [<c01020be>] cpu_idle+0x4a/0x5f handlers: [<c0254f93>] (usb_hcd_irq+0x0/0x4b) [<c0254f93>] (usb_hcd_irq+0x0/0x4b) Disabling IRQ #11 The system had been up just under 2 hours (rebooted @11:16 above message @13:15)
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
This bug has been mass-closed along with other bugs that have been in NEEDINFO state for several months. Due to the large volume of inactive bugs in bugzilla, this is the only method we have of cleaning out stale bug reports where the reporter has disappeared. If you can reproduce this bug after installing all the current updates, please reopen this bug. If you are not the reporter, you can add a comment requesting it be reopened, and someone will get to it asap. Thank you.
Well, it was only 6 weeks since you asked me to retest this & I had to get the machine out of the attic!. However, I'm afraid that this is still a problem in 2.6.14-1.1805_FC5 although the error message has changed a bit (irqpoll is new to me). System had been up about 80 minutes when I got this. Jan 1 16:48:45 bessie kernel: irq 185: nobody cared (try booting with the "irqpoll" option) Jan 1 16:48:45 bessie kernel: [<c014385c>] __report_bad_irq+0x2b/0x69 [<c0143924>] note_interrupt+0x71/0x95 Jan 1 16:48:45 bessie kernel: [<c0143321>] __do_IRQ+0xac/0xdf [<c0104e9e>] do_IRQ+0x62/0x7d Jan 1 16:48:45 bessie kernel: ======================= Jan 1 16:48:45 bessie kernel: [<c01038e2>] common_interrupt+0x1a/0x20 [<c0101018>] default_idle+0x0/0x55 Jan 1 16:48:45 bessie kernel: [<c0101044>] default_idle+0x2c/0x55 [<c01010fe>] cpu_idle+0x91/0xaa Jan 1 16:48:45 bessie kernel: [<c03cd7b0>] start_kernel+0x187/0x189 Jan 1 16:48:45 bessie kernel: handlers: Jan 1 16:48:45 bessie kernel: [<e0876bcf>] (rtl8139_interrupt+0x0/0x19f [8139too]) Jan 1 16:48:45 bessie kernel: Disabling IRQ #185 Jan 1 16:48:50 bessie kernel: irq 11: nobody cared (try booting with the "irqpoll" option) Jan 1 16:48:50 bessie kernel: [<c014385c>] __report_bad_irq+0x2b/0x69 [<c0143924>] note_interrupt+0x71/0x95 Jan 1 16:48:50 bessie kernel: [<c0143321>] __do_IRQ+0xac/0xdf [<c0104e9e>] do_IRQ+0x62/0x7d Jan 1 16:48:50 bessie kernel: ======================= Jan 1 16:48:50 bessie kernel: [<c01038e2>] common_interrupt+0x1a/0x20 [<c0101018>] default_idle+0x0/0x55 Jan 1 16:48:50 bessie kernel: [<c0101044>] default_idle+0x2c/0x55 [<c01010fe>] cpu_idle+0x91/0xaa Jan 1 16:48:50 bessie kernel: handlers: Jan 1 16:48:50 bessie kernel: [<c02722c1>] (usb_hcd_irq+0x0/0x50) Jan 1 16:48:50 bessie kernel: [<c02722c1>] (usb_hcd_irq+0x0/0x50) Jan 1 16:48:50 bessie kernel: Disabling IRQ #11
Does any ACPI-enabled kernel of any age handle this system? For the recent failing kernel, does "acpi=noirq" make it work? Please attach the complete output from 'dmesg -s64000' and 'cat /proc/interrupts' for the sucess and failure cases.
> Does any ACPI-enabled kernel of any age handle this system? I'm not sure - I don't currently have anything older than 2.6.10 which post-dates my original bug-report. I recall working kernels before Aug 2004 but not what their ACPI functionality was. I'll dig through my backups & see if I have some older kernels to try. > does "acpi=noirq" make it work I'll check & get back to you - "acpi=irqpoll" does appear to work. > Please attach... I'll send those the next time I boot that box.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
I've been trying for the last 12 days to reproduce this - the suspect machine has been up the entire time on different versions. But it has been working even in kernels that had problems within an hour or so of booting. Obviously I have tried to keep the software environment stable but I have had to update a few packages to run the newer (2.6.15) kernels so it looks as though something has changed to mitigate this bug (or maybe it was never in the kernel and has actually been fixed). I'm not likely to keep this hardware active for much longer anyway I'm closing the bug myself (if that's OK).