From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2 Description of problem: I see the following pop up regularly (perhaps once per session) in the system logs: irq 5: nobody cared (try booting with the "irqpoll" option. [<c013e0a0>] __report_bad_irq+0x2b/0x68 [<c013e169>] note_interrupt+0x73/0x96 [<c013d6cc>] __do_IRQ+0x1bd/0x249 [<c0104e04>] do_IRQ+0x5e/0x7a ======================= [<c01035b2>] common_interrupt+0x1a/0x20 [<c0120b50>] __do_softirq+0x2c/0x79 [<c0104edc>] do_softirq+0x38/0x3f ======================= [<c0104e16>] do_IRQ+0x70/0x7a [<c01035b2>] common_interrupt+0x1a/0x20 [<c020a182>] acpi_processor_idle+0xf1/0x1f6 [<c010108f>] cpu_idle+0x1f/0x34 [<c03a8665>] start_kernel+0x16b/0x16d handlers: [<c027c980>] (usb_hcd_irq+0x0/0x4b) Disabling IRQ #5 Yet, everything still seems to be working. Version-Release number of selected component (if applicable): kernel-2.6.10-1.770_FC3 How reproducible: Always Steps to Reproduce: 1. Switch on and boot up. 2. Use for a short while. 3. Wait for message to appear in a terminal. Actual Results: "irq 5: nobody cared" reported in syslog, followed by a backtrace, and then "Disabling IRQ #5". Additional info: The hardware is an HP zx5030EA notebook (P4 2.8 GHz, 512 Mb RAM, ATI Mobility Radeon 9200). IRQ 5 is registered to the OHCI controller, but USB still functions properly after this message (e.g., the mouse and attached storage devices). /sbin/lspci: 00:00.0 Host bridge: ATI Technologies Inc Radeon 9100 IGP Host Bridge (rev 02) 00:01.0 PCI bridge: ATI Technologies Inc Radeon 9100 IGP AGP Bridge 00:13.0 USB Controller: ATI Technologies Inc OHCI USB Controller #1 (rev 01) 00:13.1 USB Controller: ATI Technologies Inc OHCI USB Controller #2 (rev 01) 00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 16) 00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4349 00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 434c 00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4342 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC'97 Audio Controller 00:14.6 Modem: ATI Technologies Inc IXP AC'97 Modem (rev 01) 01:05.0 VGA compatible controller: ATI Technologies Inc M9+ 5C61 [Radeon Mobility 9200 (AGP)] (rev 01) 02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03) 02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) 02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01) 02:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01) 02:07.0 USB Controller: NEC Corporation USB (rev 43) 02:07.1 USB Controller: NEC Corporation USB (rev 43) 02:07.2 USB Controller: NEC Corporation USB 2.0 (rev 04) cat /proc/interrupts CPU0 0: 3232355 XT-PIC timer 1: 3803 XT-PIC i8042 2: 0 XT-PIC cascade 5: 100000 XT-PIC ohci_hcd 7: 196195 XT-PIC parport0 8: 1 XT-PIC rtc 9: 87 XT-PIC acpi 10: 257624 XT-PIC ATI IXP, ATI IXP Modem, ohci_hcd, yenta, yenta, ohci1394, radeon@pci:0000:01:05.0 11: 20330 XT-PIC ehci_hcd, ohci_hcd, ohci_hcd, eth0 12: 81 XT-PIC i8042 14: 15864 XT-PIC ide0 15: 28514 XT-PIC ide1 NMI: 0 ERR: 11 Could this be some USB device generating spurious signals?
I've just now found that freshly-attached USB devices aren't recognised: Mar 20 13:24:49 localhost kernel: usb 5-1: new full speed USB device using ohci_hcd and address 2 Mar 20 13:24:54 localhost kernel: ohci_hcd 0000:02:07.1: Unlink after no-IRQ? Different ACPI or APIC settings may help.
Just some more information. I noticed that the message was delivered shortly after starting to play some music. I'm using the snd-atiixp driver. Now, under Windows, PCI IRQ 5 is assigned to the AC'97 Modem and the SoundMAX Integrated Digital Audio. The OpenHCD controller is set to IRQ 19. Could this be the cause? Should I be passing a boot option to disable the APIC?
This was solved by booting an SMP kernel instead that enabled the IO-APIC.