Bug 474624 - irq 16: nobody cared; display after that only updated when other interrupts happen
irq 16: nobody cared; display after that only updated when other interrupts h...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 476870 477655 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-04 12:36 EST by Thorsten Leemhuis
Modified: 2009-12-18 02:09 EST (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:09:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci from my machine (Intel GMA965) (2.48 KB, text/plain)
2008-12-04 12:36 EST, Thorsten Leemhuis
no flags Details
Xorg.0.log (94.85 KB, text/plain)
2008-12-04 12:37 EST, Thorsten Leemhuis
no flags Details

  None (edit)
Description Thorsten Leemhuis 2008-12-04 12:36:17 EST
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
Comment 1 Thorsten Leemhuis 2008-12-04 12:36:53 EST
Created attachment 325710 [details]
lspci from my machine (Intel GMA965)
Comment 2 Thorsten Leemhuis 2008-12-04 12:37:38 EST
Created attachment 325711 [details]
Xorg.0.log
Comment 3 Thorsten Leemhuis 2008-12-13 02:07:42 EST
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.
Comment 4 Charles R. Anderson 2008-12-13 15:57:18 EST
I'm using 2.6.27.9-152.rc2.fc10.x86_64 now, and so far no issues.
Comment 5 Thorsten Leemhuis 2008-12-17 10:39:39 EST
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
Comment 6 Hedayat Vatankhah 2008-12-20 17:45:45 EST
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. :(
Comment 7 Mace Moneta 2008-12-20 17:58:41 EST
I've been running with kernel boot option acpi=routeirq, and haven't had a recurrence, yet.
Comment 8 Hedayat Vatankhah 2008-12-25 14:57:33 EST
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...
Comment 9 Tomas Hoger 2009-01-10 12:43:03 EST
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
[...]
Comment 10 herman 2009-01-11 19:56:15 EST
(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).
Comment 11 Thorsten Leemhuis 2009-01-14 00:41:22 EST
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?
Comment 12 Richard Körber 2009-01-14 04:17:13 EST
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.
Comment 13 herman 2009-01-14 16:28:34 EST
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?
Comment 14 Mace Moneta 2009-01-14 16:51:01 EST
The full text of the message says:

irq 16: nobody cared (try booting with the "irqpoll" option)

Does that answer your question?
Comment 15 herman 2009-01-14 17:03:55 EST
Thank you, I will try that..
What does that option (more or less) do?
Comment 16 Mace Moneta 2009-01-14 17:14:02 EST
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.
Comment 17 herman 2009-01-20 14:05:19 EST
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.
Comment 18 Thorsten Leemhuis 2009-01-27 12:53:16 EST
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
Comment 19 Jaroslav Barton 2009-01-27 13:12:56 EST
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.
Comment 20 Chuck Ebbert 2009-01-27 19:35:50 EST
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
Comment 21 Tomas Hoger 2009-01-28 02:47:01 EST
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.
Comment 22 Hedayat Vatankhah 2009-01-28 14:10:12 EST
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.)
Comment 23 Hedayat Vatankhah 2009-01-29 10:45:14 EST
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.
Comment 24 herman 2009-01-29 16:09:47 EST
(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..
Comment 25 herman 2009-01-29 16:12:48 EST
(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.
Comment 26 Enrico Scholz 2009-02-04 18:23:45 EST
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
Comment 27 Volker Braun 2009-02-10 09:12:14 EST
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.
Comment 28 Darius 2009-02-12 14:32:20 EST
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.
Comment 29 François Cami 2009-02-16 04:58:14 EST
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
Comment 30 Thorsten Leemhuis 2009-02-16 05:11:13 EST
(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
Comment 31 Volker Braun 2009-02-16 05:51:25 EST
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
Comment 32 Jaroslav Barton 2009-02-17 10:17:01 EST
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
Comment 33 Mark Ito 2009-02-17 11:48:10 EST
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
Comment 34 Sam Elstob 2009-02-17 13:17:04 EST
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
Comment 35 Sam Elstob 2009-02-17 13:18:24 EST
(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)
Comment 36 Enrico Scholz 2009-02-24 03:39:04 EST
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?
Comment 37 Kevin R. Page 2009-03-02 10:06:36 EST
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.
Comment 38 Kevin R. Page 2009-03-02 10:45:12 EST
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?
Comment 39 Adrian A. Sender 2009-03-03 06:02:20 EST
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)
Comment 40 Cam Webb 2009-03-08 22:31:43 EDT
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.
Comment 41 Hedayat Vatankhah 2009-03-11 04:07:31 EDT
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 :(
Comment 42 Mace Moneta 2009-03-11 12:17:51 EDT
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.
Comment 43 James Davidson 2009-03-12 22:52:00 EDT
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.
Comment 44 Mark Ito 2009-03-13 08:24:21 EDT
I tried the noirqdebug fix and have not seen the problem since. That was about a month ago.
Comment 45 Christopher J. Buckley 2009-04-07 03:18:15 EDT
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
Comment 46 François Cami 2009-04-07 14:56:17 EDT
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
Comment 48 Christopher J. Buckley 2009-04-07 15:50:24 EDT
Ignore previous comment - found appropriate firmware RPM.

http://rpmfind.net/linux/rpm2html/search.php?query=kernel-firmware
Comment 49 Tomas Hoger 2009-04-08 02:31:24 EDT
(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
Comment 50 Christopher J. Buckley 2009-04-08 09:14:50 EDT
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.
Comment 52 Christopher J. Buckley 2009-04-08 18:36:50 EDT
(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
Comment 53 Mace Moneta 2009-04-08 18:48:43 EDT
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.
Comment 54 Christopher J. Buckley 2009-04-08 18:53:17 EDT
Ok, tried kernel-2.6.29.1-15.fc10.i686 again.  Looks good so far.. !
Comment 55 Christopher J. Buckley 2009-04-08 18:54:04 EDT
(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!
Comment 56 Adrian A. Sender 2009-04-13 07:06:02 EDT
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
Comment 57 Richard Körber 2009-04-13 07:30:52 EDT
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 58 Charles R. Anderson 2009-04-14 08:40:09 EDT
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.
Comment 59 Charles R. Anderson 2009-04-14 08:47:38 EDT
*** Bug 476870 has been marked as a duplicate of this bug. ***
Comment 60 Charles R. Anderson 2009-04-14 08:49:45 EDT
*** Bug 477655 has been marked as a duplicate of this bug. ***
Comment 61 Stephen Rowles 2009-05-28 08:59:11 EDT
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
Comment 62 Bob Kennedy 2009-06-02 14:52:18 EDT
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
Comment 63 Steve 2009-07-07 11:38:35 EDT
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.
Comment 64 João Carlos Mendes Luís 2009-07-07 12:02:47 EDT
I'd like to point out that Fedora 11 kernels have apparently solved this problem, and now I can use my machine (Dell GS270).
Comment 65 Mace Moneta 2009-07-09 16:03:51 EDT
I can confirm that I have no longer encountered this on F11 (Intel G45/X4500HD).
Comment 66 Stephen Rowles 2009-07-12 03:22:49 EDT
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.
Comment 67 MartinG 2009-08-22 12:47:44 EDT
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
Comment 68 hawran.diskuse 2009-10-03 08:42:35 EDT
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?
Comment 69 Charles R. Anderson 2009-10-03 10:00:55 EDT
(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
Comment 70 hawran.diskuse 2009-10-15 07:47:18 EDT
OK, thank you.
The problem is it's a corporate notebook so there's no way for me to upgrade ...
Comment 71 Cam Webb 2009-11-02 04:05:46 EST
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)
Comment 72 hawran.diskuse 2009-11-02 07:17:00 EST
OK. I'll give it a shot ...

hawran
Comment 73 Bug Zapper 2009-11-18 04:07:43 EST
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
Comment 74 Mace Moneta 2009-11-30 01:09:06 EST
I'm no longer seeing this on F12.
Comment 75 hawran.diskuse 2009-11-30 03:18:58 EST
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, :-(
Comment 76 hawran.diskuse 2009-11-30 03:20:32 EST
Jeez, that comment is 73, of course. Sorry for that!
Comment 77 Bug Zapper 2009-12-18 02:09:23 EST
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.

Note You need to log in before you can comment on or make changes to this bug.