Description of problem: Got a kernel warnings today: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.27.7-134.fc10.x86_64 #1 Call Trace: <IRQ> [<ffffffff81083207>] __report_bad_irq+0x38/0x7c [<ffffffff81083453>] note_interrupt+0x208/0x26d [<ffffffff81083b80>] handle_fasteoi_irq+0xbb/0xeb [<ffffffff8101309e>] do_IRQ+0xf7/0x169 [<ffffffff81010933>] ret_from_intr+0x0/0x2e <EOI> [<ffffffff811bcac6>] ? acpi_idle_enter_simple+0x175/0x1b4 [<ffffffff811bcabe>] ? acpi_idle_enter_simple+0x16d/0x1b4 [<ffffffff81285f8b>] ? cpuidle_idle_call+0x95/0xc9 [<ffffffff8100f279>] ? cpu_idle+0xb2/0x10b [<ffffffff8132cd35>] ? start_secondary+0x16e/0x173 handlers: [<ffffffffa03ae465>] (i915_driver_irq_handler+0x0/0x207 [i915]) Disabling IRQ #16 After that I had to reboot, as X was pretty unusable -- the screen was only updated when interrupts from keyboard or touchpad came it. So I rebooted and a bit later got the same warning again. Both times it afaics happened when the screensaver was activated when I shut the laptop's lid (but it does not always happen when I do it) Version-Release number of selected component (if applicable): 2.6.27.7-134.fc10.x86_64 How reproducible: sporadic, but happened to me twice today (total use time of the system up to now: 2 hours). Additional info: This Bug is related, but afaics not really identical to Bug 471162 (I was affected by it as well). Seems the same or a (afaics) closely related bug is tracked here: https://bugs.freedesktop.org/show_bug.cgi?id=18609
Created attachment 325710 [details] lspci from my machine (Intel GMA965)
Created attachment 325711 [details] Xorg.0.log
FWIW, I see this problem with 2.6.27.7-137 and 2.6.27.8-144 as well; there were also two additional reports in bohi: lmacken - 2008-12-11 04:50:06 Having the same issues as thl. Kernel is only usable for a few minutes before I start dropping interrupts and eventually fully lock up. cra - 2008-12-13 03:20:36 Same issues as thl and lmacken.
I'm using 2.6.27.9-152.rc2.fc10.x86_64 now, and so far no issues.
FWIW, happend a few times again with newer kernels (see below). Trying 2.6.28-0.129.rc8.git2.fc11.x86_64 now (which worked fine for two days, but that doesn't have to mean anything) irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.27.9-157.fc10.x86_64 #1 Call Trace: <IRQ> [<ffffffff81083237>] __report_bad_irq+0x38/0x7c [<ffffffff81083483>] note_interrupt+0x208/0x26d [<ffffffff81083bb0>] handle_fasteoi_irq+0xbb/0xeb [<ffffffff8101309e>] do_IRQ+0xf7/0x169 [<ffffffff81010933>] ret_from_intr+0x0/0x2e <EOI> [<ffffffff811bd0ee>] ? acpi_idle_enter_simple+0x175/0x1b4 [<ffffffff811bd0e6>] ? acpi_idle_enter_simple+0x16d/0x1b4 [<ffffffff8128668f>] ? cpuidle_idle_call+0x95/0xc9 [<ffffffff8100f279>] ? cpu_idle+0xb2/0x10b [<ffffffff8132d505>] ? start_secondary+0x16e/0x173 handlers: [<ffffffffa0361465>] (i915_driver_irq_handler+0x0/0x207 [i915]) Disabling IRQ #16
I have the same problem with kernel 2.6.27.7-134.fc10.x86_64, while it was fixed in 2.6.27.7-117.fc10.x86_64. :(
I've been running with kernel boot option acpi=routeirq, and haven't had a recurrence, yet.
The same problem with 2.6.27.9-159: Dec 25 22:44:21 localhost kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Dec 25 22:44:21 localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.27.9-159.fc10.x86_64 #1 Dec 25 22:44:21 localhost kernel: Dec 25 22:44:21 localhost kernel: Call Trace: Dec 25 22:44:21 localhost kernel: <IRQ> [<ffffffff81083237>] __report_bad_irq+0x38/0x7c Dec 25 22:44:21 localhost kernel: [<ffffffff81083483>] note_interrupt+0x208/0x26d Dec 25 22:44:21 localhost kernel: [<ffffffff81083bb0>] handle_fasteoi_irq+0xbb/0xeb Dec 25 22:44:21 localhost kernel: [<ffffffff8101309e>] do_IRQ+0xf7/0x169 Dec 25 22:44:21 localhost kernel: [<ffffffff81010933>] ret_from_intr+0x0/0x2e Dec 25 22:44:21 localhost kernel: <EOI> [<ffffffff8105e5dd>] ? tick_nohz_stop_sched_tick+0x2ec/0x301 Dec 25 22:44:21 localhost kernel: [<ffffffff8105e854>] ? tick_nohz_restart_sched_tick+0x171/0x179 Dec 25 22:44:21 localhost kernel: [<ffffffff8100f1f1>] ? cpu_idle+0x2a/0x10b Dec 25 22:44:21 localhost kernel: [<ffffffff8132d525>] ? start_secondary+0x16e/0x173 Dec 25 22:44:21 localhost kernel: Dec 25 22:44:21 localhost kernel: handlers: Dec 25 22:44:21 localhost kernel: [<ffffffff8122a326>] (ahci_interrupt+0x0/0x4aa) Dec 25 22:44:21 localhost kernel: [<ffffffff8123b946>] (usb_hcd_irq+0x0/0xb3) Dec 25 22:44:21 localhost kernel: [<ffffffffa00a954f>] (yenta_interrupt+0x0/0xc0 [yenta_socket]) Dec 25 22:44:21 localhost kernel: Disabling IRQ #16 Occurred at least 3 times and locked when I was restarting my system. I'll stick with 2.6.27.7-117 for now...
Got this on ThinkPad T61 with Intel GM965 with kernel kernel-2.6.27.9-159.fc10.x86_64, though seems to occur in an unpredictable times, always happened when computer was not actively used. irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.27.9-159.fc10.x86_64 #1 Call Trace: <IRQ> [<ffffffff81083237>] __report_bad_irq+0x38/0x7c [<ffffffff81083483>] note_interrupt+0x208/0x26d [<ffffffff81083bb0>] handle_fasteoi_irq+0xbb/0xeb [<ffffffff8101309e>] do_IRQ+0xf7/0x169 [<ffffffff81010933>] ret_from_intr+0x0/0x2e <EOI> [<ffffffff811bd0ee>] ? acpi_idle_enter_simple+0x175/0x1b4 [<ffffffff811bd0e6>] ? acpi_idle_enter_simple+0x16d/0x1b4 [<ffffffff812866af>] ? cpuidle_idle_call+0x95/0xc9 [<ffffffff8100f279>] ? cpu_idle+0xb2/0x10b [<ffffffff8132d525>] ? start_secondary+0x16e/0x173 handlers: [<ffffffff8122a326>] (ahci_interrupt+0x0/0x4aa) [<ffffffff8123b946>] (usb_hcd_irq+0x0/0xb3) [<ffffffffa014354f>] (yenta_interrupt+0x0/0xc0 [yenta_socket]) [<ffffffffa038c465>] (i915_driver_irq_handler+0x0/0x207 [i915]) Disabling IRQ #16 # grep 16: /proc/interrupts 16: 146900 168888 IO-APIC-fasteoi ahci, uhci_hcd:usb5, yenta, i915@pci:0000:00:02.0 Followed by a SATA reset and a bunch of IO errors for sda, followed by a RO remount of disk partitions: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen ata1.00: cmd ca/00:08:82:ad:5b/00:00:00:00:00/e0 tag 0 dma 4096 out res 40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout) ata1.00: status: { DRDY } ata1: hard resetting link ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1: hard resetting link ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1: hard resetting link ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1.00: disabled ata1: hard resetting link ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1: EH complete sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 6008194 Buffer I/O error on device dm-0, logical block 698765 lost page write due to I/O error on dm-0 sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK end_request: I/O error, dev sda, sector 78628009 Buffer I/O error on device dm-1, logical block 2097164 lost page write due to I/O error on dm-1 [...]
(In reply to comment #9) > Got this on ThinkPad T61 with Intel GM965 with kernel > kernel-2.6.27.9-159.fc10.x86_64, though seems to occur in an unpredictable > times, always happened when computer was not actively used. > (...) Same issue here on Thinkpad R61e, with Intel GM965; and kernel 2.6.27.9-159.fc10.i686 Happened after, for instance, logging out a user, trying to shut down, or trying to suspend: Disabling IRQ #16 then hangs; but unpredictable when it will happen. I can still go to tty2 with Ctrl Alt F2 but trying to log in as root to shutdown nicely doesn't help either (will show same "Disabling IRQ #16", then hangs).
happened to me again an an hour or two after installing and booting into 2.6.28-3.fc10.x86_64 today: Pid: 0, comm: swapper Not tainted 2.6.28-3.fc10.x86_64 #1 Call Trace: <IRQ> [<ffffffff81089667>] __report_bad_irq+0x38/0x87 [<ffffffff810897c4>] note_interrupt+0x10e/0x172 [<ffffffff81089e82>] handle_fasteoi_irq+0xac/0xdb [<ffffffff81013dcf>] do_IRQ+0xfc/0x175 [<ffffffff81011758>] ret_from_intr+0x0/0x2e <EOI> [<ffffffff811d171a>] ? acpi_idle_enter_simple+0x175/0x1b4 [<ffffffff811d1712>] ? acpi_idle_enter_simple+0x16d/0x1b4 [<ffffffff812a1060>] ? cpuidle_idle_call+0x8c/0xc4 [<ffffffff81010242>] ? cpu_idle+0x5b/0xb4 [<ffffffff81350e1f>] ? start_secondary+0x197/0x19c handlers: [<ffffffffa03bfaae>] (i915_driver_irq_handler+0x0/0x206 [i915]) Disabling IRQ #16 Again somewhen between closing and opening the laptops lid. Before that I have been running kernel-2.6.28-1.fc11.x86_64 and other late 2.6.28-rc's from rawhide on this machine for three or four weeks without any problems. Wild guess: A race somewhere that doesn't show up when debug option are enabled?
Same here, like Tomas Hoger in Comment #9, the SATA errors included. Here it's a ThinkPad R61 with Intel chipset, and also kernel-2.6.27.9-159.fc10.x86_64. The strange thing is that the notebook was working fine until about three days ago. The only major change I did was installing VMware a few days before that. I don't know if this is related or just a coincidence. Bug 477655 seems to be a duplicate.
It seems plenty kernels are affected.. what would be a reasonable workaround (some kernel options at boot time or something) for this bug for the time being, without losing too much functionality?
The full text of the message says: irq 16: nobody cared (try booting with the "irqpoll" option) Does that answer your question?
Thank you, I will try that.. What does that option (more or less) do?
If you have the kernel-doc package installed, in /usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt irqpoll [HW] When an interrupt is not handled search all handlers for it. Also check all handlers each timer interrupt. Intended to get systems with badly broken firmware running.
Botting with the irqpoll option does not prevent the problem from occurring. (For a while I thought it did.) With 2.6.27.9-159.fc10.i686, and having booted with the irqpoll option, laptop becomes unworkable. Try to reboot, result: hangs at the same IRQ 16 issue. Then have to brute force a shutdown.
Anyone any ideas how to debug it further? it still happens round about once per day right now for me with 2.6.28.1-19.fc10.x86_64. Seems it always happens when the machine is idle and either the screensaver is active or the screen is dimmed/put into power saving mode by gnome-power-manager
Same for me: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 18370, comm: X Not tainted 2.6.27.12-170.2.5.fc10.x86_64 #1 Call Trace: <IRQ> [<ffffffff810834b3>] __report_bad_irq+0x38/0x7c [<ffffffff810836ff>] note_interrupt+0x208/0x26d [<ffffffff81083e2c>] handle_fasteoi_irq+0xbb/0xeb [<ffffffff81011bcc>] ? call_softirq+0x1c/0x28 [<ffffffff8101309e>] do_IRQ+0xf7/0x169 [<ffffffff81010933>] ret_from_intr+0x0/0x2e <EOI> handlers: [<ffffffff8122a8a6>] (ahci_interrupt+0x0/0x4aa) [<ffffffff8123bec6>] (usb_hcd_irq+0x0/0xb3) [<ffffffffa01aa54f>] (yenta_interrupt+0x0/0xc0 [yenta_socket]) Disabling IRQ #16 I am running 2.6.27.12-170.2.5.fc10.x86_64. With the irqpoll option, laptop becomes unworkable.
The workaround for this problem is "noirqdebug" not "irqpoll". There will still be spurious interrupts but they will just be ignored. "irqpoll" - fixes problems where interrupts are not being delivered "noirqdebug" - fixes problems where interrupts are arriving but nobody cares
Some reports say that booting 2.6.28 with pci=msi helped on T61. Since running with irqpoll irqfixup, I have not seen the crash as in comment #9 again yet.
Surprisingly, I don't have any problems with 2.6.27.12-170.2.5.fc10.x86_64 after 4 hours of working. I hope that I won't see this problem again. (My system (x drivers, etc) is completely updated to the latest Fedora 10 updates.)
Well, it did much better than other kernels, but it crashed today after 7-8 hours of working. :( I returned to 2.6.27.5-117 again.
(In reply to comment #23) > Well, it did much better than other kernels, but it crashed today after 7-8 > hours of working. :( I returned to 2.6.27.5-117 again. Same story here. I was running 2.6.27.12-170.2.5.fc10.i686 (same as yours but 32 bit); seemed promising here too, until eventually it did crash the entire system again. /me is back on 2.6.27.5-117 too..
(In reply to comment #24) > (In reply to comment #23) > > Well, it did much better than other kernels, but it crashed today after 7-8 > > hours of working. :( I returned to 2.6.27.5-117 again. > > Same story here. > I was running 2.6.27.12-170.2.5.fc10.i686 (same as yours but 32 bit); seemed > promising here too, until eventually it did crash the entire system again. > /me is back on 2.6.27.5-117 too.. Excuse me I forgot to mention that I was already running 2.6.27.12-170.2.5.fc10.i686 with the noirqdebug option by default. I.e., that option did not prevent the system from grinding to a halt.
New kernel does not fix it: ---- irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.27.12-170.2.5.fc10.x86_64 #1 Call Trace: <IRQ> [<ffffffff810834b3>] __report_bad_irq+0x38/0x7c [<ffffffff810836ff>] note_interrupt+0x208/0x26d [<ffffffff81083e2c>] handle_fasteoi_irq+0xbb/0xeb [<ffffffff8101309e>] do_IRQ+0xf7/0x169 [<ffffffff81010933>] ret_from_intr+0x0/0x2e <EOI> [<ffffffff8105e8a1>] ? tick_nohz_stop_sched_tick+0x2ec/0x301 [<ffffffff8105eb18>] ? tick_nohz_restart_sched_tick+0x171/0x179 [<ffffffff8100f1f1>] ? cpu_idle+0x2a/0x10b [<ffffffff8132008d>] ? rest_init+0x61/0x63 handlers: [<ffffffff8122a8a6>] (ahci_interrupt+0x0/0x4aa) [<ffffffff8123bec6>] (usb_hcd_irq+0x0/0xb3) [<ffffffffa010c54f>] (yenta_interrupt+0x0/0xc0 [yenta_socket]) [<ffffffffa0424465>] (i915_driver_irq_handler+0x0/0x207 [i915]) Disabling IRQ #16 ---- before this happens, there is an interrupt storm (check with 'cat /proc/interrupts') on IRQ16. All these irq* kernel params might hide symptoms ("Disabling IRQ #16" -> lockup due to disabled AHCI driver) but don't fix the problem. You will still see major system slowdowns. Problem appeared after an 2.6.27.5-117.fc10.x86_64 -> 2.6.27.9-159.fc10.x86_64 upgrade; with old kernel I had usual Linux uptimes, with new one, system crashes every 3-4 days. For the record: T61 64635BG
I think I found the solution: boot with the kernel parameter pci=msi (In retrospect, see comment #21 by Tomas Hoger). I had exactly the same symptoms, first the 60khz irq storm making the mouse pointer jumpy and eventually irq16: nobody cared and/or the report_bad_irq. With desktop-effects running I usually hit this bug in a few hours. I've been running 2.6.28.1-19.fc10.x86_64 and desktop-effects now for >1 day and everything is still working perfectly. I believe that Fedora disables MSI by default. This would explain why mostly fedora users are reporting this bug; My impression is that it is less/not present in other distribution's bugtrackers. In http://bugzilla.kernel.org/show_bug.cgi?id=12356 Eric Anholt says that MSI is necessary "for stable graphics on this chipset". For the record, I have a Thinkpad T61 15.4", intel 965GM X3100 video. Nothing broke by enabling MSI as far as I can tell. ===== Note 1 ===== /proc/interrupts with pci=msi CPU0 CPU1 0: 10479946 10325192 IO-APIC-edge timer 1: 5 4 IO-APIC-edge i8042 4: 1 0 IO-APIC-edge 7: 0 0 IO-APIC-edge parport0 8: 1 0 IO-APIC-edge rtc0 9: 368 100092 IO-APIC-fasteoi acpi 12: 72 78 IO-APIC-edge i8042 14: 317535 296990 IO-APIC-edge ata_piix 15: 424 405 IO-APIC-edge ata_piix 16: 0 0 IO-APIC-fasteoi uhci_hcd:usb5, yenta 17: 157 1669 IO-APIC-fasteoi uhci_hcd:usb6, HDA Intel, firewire_ohci 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb7, mmc0 19: 0 0 IO-APIC-fasteoi ehci_hcd:usb2 20: 80 89 IO-APIC-fasteoi uhci_hcd:usb3 21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 92 215306 IO-APIC-fasteoi ehci_hcd:usb1 2297: 2615355 2467645 PCI-MSI-edge i915@pci:0000:00:02.0 2298: 5 269711 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 7200475 10987750 Local timer interrupts RES: 4707113 3913112 Rescheduling interrupts CAL: 360 107 Function call interrupts TLB: 10540 11346 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 Without pci=msi, irq 16 was shared by uhci_hcd, yenta, and i915. ===== Note 2 ===== Without pci=msi, i also got the following: Feb 8 17:22:19 t61 kernel: e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6 Feb 8 17:22:19 t61 kernel: e1000e: Copyright (c) 1999-2008 Intel Corporation. Feb 8 17:22:19 t61 kernel: e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 Feb 8 17:22:19 t61 kernel: 0000:00:19.0: 0000:00:19.0: Failed to initialize MSI interrupts. Falling back to legacy interrupts. With pci=msi, there is no such error. ===== Note 3 ===== I still get the following kernel message occasionally: Feb 9 13:47:49 t61 kernel: CE: hpet increasing min_delta_ns to 15000 nsec My original impression was that this error often occurred around the start of the irq storm, but apparently it is unrelated.
FYI, I tried pci=msi with 2.6.27.12-170.2.5.fc10.i686 on a T61 6465-CTO, but it didn't move the video controller to MSI (it stayed on irq 16): % grep i915 /proc/interrupts 16: 56265 0 IO-APIC-fasteoi uhci_hcd:usb5, yenta, i915@pci:0000:00:02.0 Eventually I got the interrupt storm (jerky mouse movements, etc). I tried 2.6.28.1-19, but the graphical login froze and I got messages like this: Feb 12 13:00:41 localhost kernel: usb 3-2: usbfs: process 3406 (gdm-session-wor) did not claim interface 0 before use I think this is related to the fingerprint reader. I guess I'll try going back to 2.6.27.5-117.
Thorsten, Could you try each of the following kernel arguments and report : noirqdebug pci=msi Possible related bugs : 476870, 477655 --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #29) > Could you try each of the following kernel arguments and report : > noirqdebug > pci=msi I'm using 2.6.29-rc*fc10 kernels from koji for some weeks now with pci=msi and it works fine. I haven't found time yet to run 2.6.27 again with pci=msi to check if that solves the problem as well
Intel issued some errata stating that MSI causes problems with GMA965 (on device 2 only, whatever that means), with the only offered fix to disable it. In 2.6.27-rc1 this was implemented and MSI was forcefully disabled: i915: Disable MSI on GM965 (errata says it doesn't work) In 2.6.28-rc8 this was reverted as it became clear that it was counterproductive: drm/i915: Disable the GM965 MSI errata workaround. Therefore the pci=msi option will not fix this bug on kernels < 2.6.28
Just tried kernel 2.6.28.1-19.fc10.x86_64 from koji with pci=msi and result is: 6353 Feb 17 16:09:36 loki kernel: Bad page state in process 'kdm_greet' 6354 Feb 17 16:09:36 loki kernel: page:ffffe200015bffe8 flags:0x0020000000000008 mapping:1100002b00000000 mapcount:0 count:0 (Not tainted) 6355 Feb 17 16:09:36 loki kernel: Trying to fix it up, but a reboot is needed 6356 Feb 17 16:09:36 loki kernel: Backtrace: 6357 Feb 17 16:09:36 loki kernel: Pid: 4263, comm: kdm_greet Not tainted 2.6.28.1-19.fc10.x86_64 #1 6358 Feb 17 16:09:36 loki kernel: Call Trace: 6359 Feb 17 16:09:36 loki kernel: [<ffffffff8109b391>] bad_page+0x82/0xb2 6360 Feb 17 16:09:36 loki kernel: [<ffffffff810a4bac>] ? zone_statistics+0x62/0x67 6361 Feb 17 16:09:36 loki kernel: [<ffffffff8109d016>] get_page_from_freelist+0x478/0x6d4 6362 Feb 17 16:09:36 loki kernel: [<ffffffff8109d59c>] __alloc_pages_internal+0xfe/0x45a 6363 Feb 17 16:09:36 loki kernel: [<ffffffff810a01f2>] ? __lru_cache_add+0x34/0x7c 6364 Feb 17 16:09:36 loki kernel: [<ffffffff810bd8fa>] alloc_page_vma+0xc1/0xc6 6365 Feb 17 16:09:36 loki kernel: [<ffffffff810a9274>] handle_mm_fault+0x1b9/0x8f1 6366 Feb 17 16:09:36 loki kernel: [<ffffffff81121d73>] ? ext3_get_block+0x0/0xfc 6367 Feb 17 16:09:36 loki kernel: [<ffffffff8109d59c>] ? __alloc_pages_internal+0xfe/0x45a 6368 Feb 17 16:09:36 loki kernel: [<ffffffff81121d73>] ? ext3_get_block+0x0/0xfc 6369 Feb 17 16:09:36 loki kernel: [<ffffffff81029b87>] ? default_spin_lock_flags+0x9/0xe 6370 Feb 17 16:09:36 loki kernel: [<ffffffff81029b87>] ? default_spin_lock_flags+0x9/0xe 6371 Feb 17 16:09:36 loki kernel: [<ffffffff81359729>] do_page_fault+0x64b/0xa99 6372 Feb 17 16:09:36 loki kernel: [<ffffffff8109f388>] ? __do_page_cache_readahead+0xf8/0x163 6373 Feb 17 16:09:36 loki kernel: [<ffffffff81029ac2>] ? __ticket_spin_lock+0xe/0x1a 6374 Feb 17 16:09:36 loki kernel: [<ffffffff813569da>] ? _spin_lock+0x9/0xc 6375 Feb 17 16:09:36 loki kernel: [<ffffffff810e1970>] ? mnt_drop_write+0x82/0x143 6376 Feb 17 16:09:36 loki kernel: [<ffffffff810e0219>] ? mnt_want_write+0x77/0x8d 6377 Feb 17 16:09:36 loki kernel: [<ffffffff810dd20f>] ? touch_atime+0xda/0xfc 6378 Feb 17 16:09:36 loki kernel: [<ffffffff81098cd5>] ? generic_file_aio_read+0x503/0x55e 6379 Feb 17 16:09:36 loki kernel: [<ffffffff810cc8a0>] ? do_sync_read+0xe7/0x12d 6380 Feb 17 16:09:36 loki kernel: [<ffffffff8105a705>] ? autoremove_wake_function+0x0/0x38 6381 Feb 17 16:09:36 loki kernel: [<ffffffff81042f8b>] ? finish_task_switch+0x31/0xc9 6382 Feb 17 16:09:36 loki kernel: [<ffffffff813569da>] ? _spin_lock+0x9/0xc 6383 Feb 17 16:09:36 loki kernel: [<ffffffff810cc3cd>] ? fsnotify_access+0x62/0x6a 6384 Feb 17 16:09:36 loki kernel: [<ffffffff813568ab>] ? trace_hardirqs_off_thunk+0x3a/0x6c 6385 Feb 17 16:09:36 loki kernel: [<ffffffff81356e7f>] error_exit+0x0/0x75 after second login system freezes
I am seeing this as well. Running on a Dell Latitude E4300. On console: Message from syslogd@laptop-marki at Feb 17 11:02:14 ... kernel:Disabling IRQ #16 from /var/log/messages: Feb 17 11:02:14 laptop-marki kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Feb 17 11:02:14 laptop-marki kernel: Pid: 9630, comm: fitter Tainted: P 2.6.27.12-170.2.5.fc10.i686 #1 Feb 17 11:02:14 laptop-marki kernel: [<c0464a64>] __report_bad_irq+0x2e/0x6f Feb 17 11:02:14 laptop-marki kernel: [<c0464c73>] note_interrupt+0x1ce/0x223 Feb 17 11:02:14 laptop-marki kernel: [<c04641e4>] ? handle_IRQ_event+0x5c/0x64 Feb 17 11:02:14 laptop-marki kernel: [<c0465234>] handle_fasteoi_irq+0x99/0xc0 Feb 17 11:02:14 laptop-marki kernel: [<c046519b>] ? handle_fasteoi_irq+0x0/0xc0 Feb 17 11:02:14 laptop-marki kernel: [<c0405e52>] do_IRQ+0xc7/0xfe Feb 17 11:02:14 laptop-marki kernel: [<c040464c>] common_interrupt+0x28/0x30 Feb 17 11:02:14 laptop-marki kernel: ======================= Feb 17 11:02:14 laptop-marki kernel: handlers: Feb 17 11:02:14 laptop-marki kernel: [<f8f51055>] (i915_driver_irq_handler+0x0/0x1cf [i915]) Feb 17 11:02:14 laptop-marki kernel: Disabling IRQ #16
I see this as well Feb 11 12:00:05 deben kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Feb 11 12:00:05 deben kernel: Pid: 18128, comm: cc1 Tainted: P 2.6.27.9-159.fc10.x86_64 #1 Feb 11 12:00:05 deben kernel: Feb 11 12:00:05 deben kernel: Call Trace: Feb 11 12:00:05 deben kernel: <IRQ> [<ffffffff81083237>] __report_bad_irq+0x38/0x7c Feb 11 12:00:05 deben kernel: [<ffffffff81083483>] note_interrupt+0x208/0x26d Feb 11 12:00:05 deben kernel: [<ffffffff81083bb0>] handle_fasteoi_irq+0xbb/0xeb Feb 11 12:00:05 deben kernel: [<ffffffff8101309e>] do_IRQ+0xf7/0x169 Feb 11 12:00:05 deben kernel: [<ffffffff81010933>] ret_from_intr+0x0/0x2e Feb 11 12:00:05 deben kernel: <EOI> Feb 11 12:00:05 deben kernel: handlers: Feb 11 12:00:05 deben kernel: [<ffffffff8123b946>] (usb_hcd_irq+0x0/0xb3) Feb 11 12:00:05 deben kernel: [<ffffffffa006f5ee>] (rtl8168_interrupt+0x0/0x299 [r8168]) Feb 11 12:00:05 deben kernel: [<ffffffffa03f3465>] (i915_driver_irq_handler+0x0/0x207 [i915]) Feb 11 12:00:05 deben kernel: Disabling IRQ #16
(In reply to comment #34) > I see this as well > Sorry forgot to say what hardware - a Dell Vostro 1510 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03) 06:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 08:05.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 08:05.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 02) 08:05.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01)
still with kernel-2.6.27.15-170.2.24.fc10.x86_64 and 'pci=msi'. What have we to do that this bug gets fixed in Fedora?
Thinkpad X61s, Intel GM965/GL960, kernel 2.6.27.12-170.2.5.fc10.i686 I start suffering from jerky mouse pointer movements (interrupt storm); this makes the desktop unusable, and when I go to reboot I see: Mar 1 17:30:03 mopp kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Mar 1 17:30:03 mopp kernel: Pid: 0, comm: swapper Not tainted 2.6.27.12-170.2.5.fc10.i686 #1 Mar 1 17:30:03 mopp kernel: [<c0464a64>] __report_bad_irq+0x2e/0x6f etc. go past. I'll try 'pci=msi', although comment #31 suggests this will be ineffectual. Just in case it could be related, I've suffered interrupt problems in the past - bug #246056. It seems like that one turned out to be a BIOS incompatibility.
I also have: kernel: CE: hpet increasing min_delta_ns to 15000 nsec in my logs, and it seems to be logged about when the mouse jerkiness starts - though it's not clear from the above comments whether this is related?
I also have the same issue on F10 x86 Lenovo T61. Mouse is really unusable - external usb mouse has same issue. Mar 2 02:19:43 localhost kernel: irq 16: nobody cared (try booting with the "irqpoll" option)
Same IRQ #16 issue on a Lenovo X61 with kernel 2.6.27.15-170.2.24.fc10.i686 (and with two previous F10 kernels). # cat /proc/interrupts ... 16: 1963008 70992 IO-APIC-fasteoi ahci, uhci_hcd:usb5, yenta, i915@ pci:0000:00:02.0 ... 19: 399869 132 IO-APIC-fasteoi ehci_hcd:usb2 ... [ I also get a separate ``Disabling IRQ #19'' (USB 2) failure, usually with the first suspend/resume cycle, but this does not kill the system. Only one USB port generally works (Bus 004 Device 005). ] Never had these problem with F8. Unpredictable time to IRQ #16 issue/crash: from 10 mins to 10 hours. Same jerky mouse icon, and then a hang when trying to cleanly shut down. This is a major hassle (too many unclean /home umounts). Hope someone can fix this. Thx.
Hi, Does this happen on rawhide too? If it does, I think this bug should be added to F11 Blocker list, since it'll make F11 unusable on such hardware :(
I'm running rawhide (since F11 alpha), and used to get this error in F10. It's hard to tell if this problem occurs with rawhide, because X locks up periodically with no messages or errors: bug #473347. The longest I've gone before a lockup is less than three days, so one bug could be masking the other.
I installed kernel-2.6.29-0.53.rc7.fc10.x86_64 from koji 6 days ago on my Lenovo T61 which exhibited this issue with kernel-2.6.27.19-170.2.35.fc10.x86_64. The problem would occur about once a day for me with the 2.6.27 kernel but has not occurred since I upgraded the kernel.
I tried the noirqdebug fix and have not seen the problem since. That was about a month ago.
I experience the same: kernel-2.6.27.21-170.2.56.fc10.i686 LSB Version: :core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch Distributor ID: Fedora Description: Fedora release 10 (Cambridge) Release: 10 Codename: Cambridge Apr 7 08:03:37 ahx-thinkpad kernel: Breaking affinity for irq 12 Apr 7 08:03:37 ahx-thinkpad kernel: Breaking affinity for irq 16 Apr 7 08:03:37 ahx-thinkpad kernel: Breaking affinity for irq 18 Apr 7 08:03:37 ahx-thinkpad kernel: Breaking affinity for irq 20 Apr 7 08:03:37 ahx-thinkpad kernel: Breaking affinity for irq 22 Apr 7 08:09:33 ahx-thinkpad kernel: irq 19: nobody cared (try booting with the "irqpoll" option) Apr 7 08:09:33 ahx-thinkpad kernel: [<c0465ba4>] __report_bad_irq+0x2e/0x6f Apr 7 08:09:33 ahx-thinkpad kernel: [<c0466374>] handle_fasteoi_irq+0x99/0xc0 Apr 7 08:09:33 ahx-thinkpad kernel: [<c04662db>] ? handle_fasteoi_irq+0x0/0xc0 Apr 7 08:09:33 ahx-thinkpad kernel: [<c05d4568>] (usb_hcd_irq+0x0/0xa3) then: [root@ahx-thinkpad ~]# Message from syslogd@ahx-thinkpad at Apr 7 08:09:33 ... kernel:Disabling IRQ #19
Christopher, Could you please try kernel-2.6.29.1-15.fc10 or similar / more recent from Koji ? http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Please report if it works for you. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Ignore previous comment - found appropriate firmware RPM. http://rpmfind.net/linux/rpm2html/search.php?query=kernel-firmware
(In reply to comment #48) > Ignore previous comment - found appropriate firmware RPM. > > http://rpmfind.net/linux/rpm2html/search.php?query=kernel-firmware kernel-firmware is one of the subrpms built from kernel srpm... see e.g. http://koji.fedoraproject.org/koji/buildinfo?buildID=96454
Tried kernel-2.6.29.1-15.fc10 - went straight back to .27 after a days use. Constant kernel lockups after resume, or when utilising wi-fi.
(In reply to comment #49) > (In reply to comment #48) > > Ignore previous comment - found appropriate firmware RPM. > > > > http://rpmfind.net/linux/rpm2html/search.php?query=kernel-firmware > > kernel-firmware is one of the subrpms built from kernel srpm... > see e.g. http://koji.fedoraproject.org/koji/buildinfo?buildID=96454 Right.. But, where is the kernel-firmware RPM? Forgive me if I am not seeing it, but I don't see this RPM. Help? Cheers, Chris
You can use your browser's find function to find text on the screen that you are looking for. The firmware rpm is in the noarch section of the package list.
Ok, tried kernel-2.6.29.1-15.fc10.i686 again. Looks good so far.. !
(In reply to comment #53) > You can use your browser's find function to find text on the screen that you > are looking for. The firmware rpm is in the noarch section of the package > list. Ah, good grief - d'oh! Right in front of me. Apologies. Got it installed now! Cheers!
Running the suggested kernel the problem still appears. This has been going on for quite a long time - be nice to have it fixed asap! irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.29.1-15.fc10.i686 #1 Call Trace: [<c0468d62>] __report_bad_irq+0x2e/0x6f [<c0468e93>] note_interrupt+0xf0/0x149 [<c04693c9>] handle_fasteoi_irq+0x8f/0xb5 [<c046933a>] ? handle_fasteoi_irq+0x0/0xb5 <IRQ> [<c040442c>] ? common_interrupt+0x2c/0x34 [<c0580084>] ? acpi_idle_enter_simple+0x140/0x17b [<c06367bc>] ? cpuidle_idle_call+0x60/0x94 [<c0402e20>] ? cpu_idle+0x6b/0x8b [<c06d1328>] ? start_secondary+0x1c9/0x1d1 handlers: [<c05f245d>] (usb_hcd_irq+0x0/0xa3) [<f7eda2e9>] (yenta_interrupt+0x0/0xbe [yenta_socket]) [<f82808fb>] (i915_driver_irq_handler+0x0/0x1d5 [i915]) Disabling IRQ #16
With Kernel 2.6.27.21-170.2.56.fc10.x86_64, this bug still appears with either pci=msi or noirqdebug kernel option set. Anyhow, with noirqdebug set, the bug only occured here so far after waking up from suspend-to-RAM. Possible duplicates are Bug 476870 and Bug 477655. I would help and close them as dupes myself, but I haven't got the rights to do so. It would indeed be nice to have this bug fixed asap now. At least it should be fixed for F11.
Comment #27 and Comment #31 seem right on the money. I've been running rawhide, and have not seen this problem in a very long time on my ThinkPad T61 GMA965. F10 2.6.29-based kernels may still need the 'pci=msi' boot parameter (they did back when I had been running F10), but the F11 rawhide 2.6.29-based kernels don't as it appears to be the default there. My experience has been that 2.6.27 or 2.6.28 F10 kernels can't use 'pci=msi' with GMA965, and so they are not going to be stable at all on this hardware. This bug is basically solved for me, but it seems that F10 users need to wait for the 2.6.29 update (if it ever comes) or use the koji kernel mentioned in Comment #46 and possibly still boot with 'pci=msi'. 2.6.29 (F11 Beta/rawhide) has been great for me on my ThinkPad T61.
*** Bug 476870 has been marked as a duplicate of this bug. ***
*** Bug 477655 has been marked as a duplicate of this bug. ***
Same issue here, occurred after bring the laptop back from suspend and while network manage was trying to re-connect to my wireless AP. Various firefox pages were open, some with flash content which looks like that might have provoked the error this time. [steve@mini-manicminer ~]$ uname -a Linux mini-manicminer 2.6.27.24-170.2.68.fc10.i686 #1 SMP Hardware is an Acer Laptop - 5920 with Intel GM965/GL960 graphics. My log looks like this: May 28 13:33:38 mini-manicminer NetworkManager: <info> (wlan0): bringing up device. May 28 13:33:38 mini-manicminer kernel: iwl3945 0000:06:00.0: enabling device (0000 -> 0002) May 28 13:33:38 mini-manicminer kernel: iwl3945 0000:06:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 May 28 13:33:38 mini-manicminer kernel: Registered led device: iwl-phy0:radio May 28 13:33:38 mini-manicminer kernel: Registered led device: iwl-phy0:assoc May 28 13:33:38 mini-manicminer kernel: Registered led device: iwl-phy0:RX May 28 13:33:38 mini-manicminer kernel: Registered led device: iwl-phy0:TX May 28 13:33:38 mini-manicminer kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready May 28 13:33:38 mini-manicminer NetworkManager: <info> (wlan0): preparing device. May 28 13:33:38 mini-manicminer NetworkManager: <info> (wlan0): deactivating device (reason: 2). May 28 13:33:38 mini-manicminer NetworkManager: <info> (wlan0): device state change: 2 -> 3 May 28 13:33:38 mini-manicminer NetworkManager: <info> (wlan0): supplicant interface state: starting -> ready May 28 13:33:39 mini-manicminer kernel: irq 16: nobody cared (try booting with the "irqpoll" option) May 28 13:33:39 mini-manicminer kernel: Pid: 6488, comm: npviewer.bin Not tainted 2.6.27.24-170.2.68.fc10.i686 #1 May 28 13:33:39 mini-manicminer kernel: [<c0465bc0>] __report_bad_irq+0x2e/0x6f May 28 13:33:39 mini-manicminer kernel: [<c0465dcf>] note_interrupt+0x1ce/0x223 May 28 13:33:39 mini-manicminer kernel: [<c0465340>] ? handle_IRQ_event+0x5c/0x64 May 28 13:33:39 mini-manicminer kernel: [<c0466390>] handle_fasteoi_irq+0x99/0xc0 May 28 13:33:39 mini-manicminer kernel: [<c04662f7>] ? handle_fasteoi_irq+0x0/0xc0 May 28 13:33:39 mini-manicminer kernel: [<c0406e6e>] do_IRQ+0xc7/0xfe May 28 13:33:39 mini-manicminer kernel: [<c0405668>] common_interrupt+0x28/0x30 May 28 13:33:39 mini-manicminer kernel: ======================= May 28 13:33:39 mini-manicminer kernel: handlers: May 28 13:33:39 mini-manicminer kernel: [<c05d4720>] (usb_hcd_irq+0x0/0xa3) May 28 13:33:39 mini-manicminer kernel: [<f8c738ec>] (irq_handler+0x0/0x323 [firewire_ohci]) May 28 13:33:39 mini-manicminer kernel: [<f908e094>] (i915_driver_irq_handler+0x0/0x1d8 [i915]) May 28 13:33:39 mini-manicminer kernel: Disabling IRQ #16 May 28 13:33:40 mini-manicminer kernel: tg3: eth0: Link is up at 100 Mbps, full duplex. May 28 13:33:40 mini-manicminer kernel: tg3: eth0: Flow control is on for TX and on for RX. May 28 13:33:40 mini-manicminer NetworkManager: <info> (eth0): carrier now ON (device state 2) May 28 13:33:40 mini-manicminer NetworkManager: <info> (eth0): device state change: 2 -> 3 May 28 13:33:40 mini-manicminer NetworkManager: <info> Activation (eth0) starting connection 'Auto Ethernet' May 28 13:33:40 mini-manicminer NetworkManager: <info> (eth0): device state change: 3 -> 4
As far as I have figured out, on my laptop it seems to be related to wireless settings. - While working with wireless adapter enabled, I frequently have this bug (screen updates only when another interrupt was received, e.g. mouse move, only restart resolves this situation) /var/log/messages: Jun 1 16:47:36 localhost kernel: CE: hpet increasing min_delta_ns to 33750 nsec Jun 1 17:10:45 localhost kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Jun 1 17:10:45 localhost kernel: Pid: 0, comm: swapper Tainted: P 2.6.27.24-170.2.68.fc10.i686 #1 Jun 1 17:10:45 localhost kernel: [<c0465bc0>] __report_bad_irq+0x2e/0x6f Jun 1 17:10:45 localhost kernel: [<c0465dcf>] note_interrupt+0x1ce/0x223 Jun 1 17:10:45 localhost kernel: [<c0465340>] ? handle_IRQ_event+0x5c/0x64 Jun 1 17:10:45 localhost kernel: [<c0466390>] handle_fasteoi_irq+0x99/0xc0 Jun 1 17:10:45 localhost kernel: [<c04662f7>] ? handle_fasteoi_irq+0x0/0xc0 Jun 1 17:10:45 localhost kernel: [<c0406e6e>] do_IRQ+0xc7/0xfe Jun 1 17:10:45 localhost kernel: [<c0405668>] common_interrupt+0x28/0x30 Jun 1 17:10:45 localhost kernel: [<c05681bf>] ? acpi_idle_enter_simple+0x162/0x19d Jun 1 17:10:45 localhost kernel: [<c0617e7e>] cpuidle_idle_call+0x60/0x92 Jun 1 17:10:45 localhost kernel: [<c0403c61>] cpu_idle+0x101/0x134 Jun 1 17:10:45 localhost kernel: [<c06a7144>] start_secondary+0x197/0x19f Jun 1 17:10:45 localhost kernel: ======================= Jun 1 17:10:45 localhost kernel: handlers: Jun 1 17:10:45 localhost kernel: [<f8ff0094>] (i915_driver_irq_handler+0x0/0x1d8 [i915]) Jun 1 17:10:45 localhost kernel: Disabling IRQ #16 With wireless disabled (hardware switch on the laptop) and using fixed network connection, I do not seem to get this bug. Kernel: 2.6.27.24-170.2.68.fc10.i686 Hardware: Dell laptop E6500, Intel integrated graphics, Broadcom wireless
I am also experiencing this bug, it usually happens when I have been away from the keyboard for an extended period, not sure if it is related to some type of sleep behaviour. /var/log/messages Jul 6 11:49:43 localhost kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Jul 6 11:49:43 localhost kernel: [<c0465b38>] __report_bad_irq+0x2e/0x6f Jul 6 11:49:43 localhost kernel: [<c0466308>] handle_fasteoi_irq+0x99/0xc0 Jul 6 11:49:43 localhost kernel: [<c046626f>] ? handle_fasteoi_irq+0x0/0xc0 Jul 6 11:49:43 localhost kernel: [<f8b98055>] (i915_driver_irq_handler+0x0/0x1cf [i915]) from /var/log/pm-powersave.log when trying to resume display from sleep mode. /usr/lib/pm-utils/power.d/sched-powersave false: **sched policy powersave OFF success.
I'd like to point out that Fedora 11 kernels have apparently solved this problem, and now I can use my machine (Dell GS270).
I can confirm that I have no longer encountered this on F11 (Intel G45/X4500HD).
Great that is it fixed on F11, is it going to be fixed for F10? I don't really want to upgrade my whole OS just to fix this bug. Cheers.
I get this error on F11 kernel-2.6.29.3-142.fc11.x86_64 xorg-x11-drv-intel-2.7.0-7.fc11.x86_64 Motherboard: ASUS P5E-VM HDMI 00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03) (using i915) I think it is related to suspending the display. I do not use any other form of suspend/resume. This is the dmesg output: eth0: no IPv6 routers present audit(1250885180.709:28621): auid=4294967295 ses=4294967295 op=remove rule key=(null) list=2 res=1 audit(1250885180.709:28622): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1 irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.29.3-142.fc11.x86_64 #1 Call Trace: <IRQ> [<ffffffff8108d209>] __report_bad_irq+0x3d/0x8c [<ffffffff8108d370>] note_interrupt+0x118/0x17c [<ffffffff8108da33>] handle_fasteoi_irq+0xa7/0xde [<ffffffff81013ba4>] do_IRQ+0xd9/0x151 [<ffffffff81011e93>] ret_from_intr+0x0/0x2e <EOI> [<ffffffff81017c0a>] ? mwait_idle+0x9e/0xc7 [<ffffffff81017c01>] ? mwait_idle+0x95/0xc7 [<ffffffff813ae5b9>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff81010237>] ? enter_idle+0x27/0x29 [<ffffffff810102a1>] ? cpu_idle+0x68/0xb3 [<ffffffff813a5921>] ? start_secondary+0x199/0x19e handlers: [<ffffffff8129eb6b>] (usb_hcd_irq+0x0/0xab) [<ffffffff81288128>] (ata_sff_interrupt+0x0/0xc9) [<ffffffffa012a9eb>] (irq_handler+0x0/0x339 [firewire_ohci]) [<ffffffffa015e7bc>] (mantis_pci_irq+0x0/0x278 [mantis]) Disabling IRQ #16 This output came using the following cmdline: $ cat /proc/cmdline ro root=/dev/mapper/VolGroup00-LogVol00 rhgb quiet selinux=0 nomodeset irqpoll
Hi all, I'd like to know what is a solution then. I've been experiencing the same problem, I'd say since I'd upgraded to the 2.6.27.30-170.2.82.fc10.i686 version. ============================================= A couple of details: $ uname -a Linux xxx 2.6.27.30-170.2.82.fc10.i686 #1 SMP Mon Aug 17 08:38:59 EDT 2009 i686 i686 i386 GNU/Linux $ lsl /boot/initrd-2.6.27.30-170.2.82.fc10.i686.img -rw------- 1 root root 3203152 2009-09-22 13:58 /boot/initrd-2.6.27.30-170.2.82.fc10.i686.img $ sudo egrep 'irq 16: nobody cared' /var/log/messages* /var/log/messages:Sep 28 20:01:00 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Sep 28 20:01:28 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Sep 30 11:00:49 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Sep 30 11:01:12 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 1 08:57:06 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 1 08:58:42 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 2 12:59:07 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 2 12:59:27 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 2 21:46:11 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 3 11:04:17 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 3 11:23:59 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 3 11:25:46 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages:Oct 3 14:07:26 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages-20090928:Sep 22 19:36:58 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages-20090928:Sep 22 20:03:28 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages-20090928:Sep 22 20:31:33 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages-20090928:Sep 23 16:40:28 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) /var/log/messages-20090928:Sep 23 20:53:33 cz994691 kernel: irq 16: nobody cared (try booting with the "irqpoll" option) $ lspci 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) 00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba) 15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04) 15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21) 15:00.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff) 15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11) 15:00.5 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 11) $ cat /proc/interrupts CPU0 CPU1 0: 195209 151201 IO-APIC-edge timer 1: 4 3020 IO-APIC-edge i8042 8: 16 18 IO-APIC-edge rtc0 9: 335 2545 IO-APIC-fasteoi acpi 12: 1896 1200 IO-APIC-edge i8042 14: 9239 9301 IO-APIC-edge ata_piix 15: 10610 10475 IO-APIC-edge ata_piix 16: 1 208151 IO-APIC-fasteoi uhci_hcd:usb5, yenta, i915@pci:0000:00:02.0 17: 161 160 IO-APIC-fasteoi uhci_hcd:usb6, firewire_ohci, HDA Intel 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb7, mmc0 19: 0 0 IO-APIC-fasteoi ehci_hcd:usb2 20: 43679 23 IO-APIC-fasteoi uhci_hcd:usb3, eth0 21: 16 26374 IO-APIC-fasteoi uhci_hcd:usb4 22: 1 1 IO-APIC-fasteoi ehci_hcd:usb1 NMI: 0 0 Non-maskable interrupts LOC: 163031 243017 Local timer interrupts RES: 113352 37392 Rescheduling interrupts CAL: 309 10721 function call interrupts TLB: 217 169 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 What is wrong?
(In reply to comment #68) > Hi all, > I'd like to know what is a solution then. > I've been experiencing the same problem, I'd say since I'd upgraded to the > 2.6.27.30-170.2.82.fc10.i686 version. The solution is to upgrade to a 2.6.29 kernel for Fedora 10 (and perhaps pass pci=msi in /etc/grub.conf), or upgrade your OS to Fedora 11 which comes with 2.6.29+ (pci=msi not needed on F11). Really, I don't think they'll release a 2.6.29 for Fedora 10, so your best bet is to just upgrade to Fedora 11. I've been running F11 on a T61 for months now without this issue occurring at all. If you really want to stick with Fedora 10, here is the latest Koji build of 2.6.29 for F10 I can find: http://koji.fedoraproject.org/koji/buildinfo?buildID=127544
OK, thank you. The problem is it's a corporate notebook so there's no way for me to upgrade ...
I'm pleased to confirm that nearly a month after upgrading to kernel-2.6.29.6-99.fc10.i686 from Koji the problem has disappeared. No more IRQ storms and desperate shutdowns before a total lockup. Something seems to have been fixed between kernel-2.6.29.6-93.fc10.i686 (which still failed) and kernel-2.6.29.6-99.fc10.i686. Phew. Thanks to whoever fixed this and to Charles Anderson for pointing to the working build. Cam (Lenovo X61)
OK. I'll give it a shot ... hawran
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm no longer seeing this on F12.
OK. I thought that was about to be closed regarding comment 37 ... I upgraded to 2.6.29.6-99.fc10.i686 a couple of days ago and haven't seen that annoying behaviour since then. PS: However, my cisco vpn freezes the entire nb since then whenever I try to use the vpn connection, :-(
Jeez, that comment is 73, of course. Sorry for that!
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.