Bug 142762
Summary: | irq 11: nobody cared - Abit VP6 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Flinders <paul> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | acpi-bugzilla, djuran, pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-03 08:10:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Paul Flinders
2004-12-13 22:09:36 UTC
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). |