This is about a very specific board: Asus m2a-vm The nearly identical Asus m2a-vm-hdmi does not show "IRQ nobody cared" messages. The reason is a ohci1394 device which should not get activated. A quick google on m2a-vm (hdmi) ASUS boards shows that the m2a-vm does not support firewire at all: http://www.pcmag.co.uk/personal-computer-world/hardware/2185071/review-asus-m2a-vm-motherboard But the ohci1394 is still loaded on the m2a-vm and causing the "IRQ nobody cared" messages as it wrongly uses IRQ 19, instead of sharing IRQ 22 with ahci (as on the m2a-vm-hdmi). The reason is because the the m2a-vm DSDT misses the IRQ specification in the _PRT table of the PCI2PCI bridge which seem to be done on purpose (see link above, this board should not support firewire). It seems Windows does not try to derivate the IRQ from the parent/bridge device, but just ignores the device silently. I am going to attach: - the orginal DSDT - A DSDT portion stolen from the m2a-vm-hdmi BIOS which makes the ohci1394 be assigned to the correct IRQ - A kernel patch which adopts to the expected Windows behavior - Above patch with boot param and dmi logic if above patch is considered to be too risky Here some dmesg parts of the problem (commented with ### and acpi.debug_level=0x1F added for the extended acpi_irq info): pci_irq-0428 [00] pci_irq_lookup : Searching for PRT entry for 00:03:07[A] pci_irq-0432 [00] pci_irq_lookup : PRT entry not found ### The firewire device does not have a _PRT entry! pci_irq-0428 [00] pci_irq_lookup : Searching for PRT entry for 00:00:14[D] pci_irq-0369 [00] pci_allocate_irq : Found IRQ 19 pci_irq-0528 [00] pci_irq_derive : Derive IRQ 19 for device 0000:03:07.0 from 0000:00:14.4 ### Thus the wrong IRQ is derived from its PCI bridge ohci1394 0000:03:07.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[fdeff000-fdeff7ff] Max Packet=[512] IR/IT contexts=[4/8] ppdev: user-space parallel port driver sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors: (320GB/298GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors: (320GB/298GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 Adding 1959920k swap on /dev/hda2. Priority:-1 extents:1 across:1959920k ### The wrong IRQ immediately triggers an "IRQ nobody cared" on the IRQ line ### ohci1394 should have been assigned to: IRQ 22 where ahci is sitting: irq 22: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.27.10-HEAD_20081219191018_22cc4def-default #1 Call Trace: [<ffffffff8020e53e>] show_trace_log_lvl+0x41/0x58 [<ffffffff804ac32d>] dump_stack+0x69/0x6f [<ffffffff802821f5>] __report_bad_irq+0x30/0x7d [<ffffffff802822f8>] note_interrupt+0xb6/0xfa [<ffffffff802829de>] handle_fasteoi_irq+0xbf/0xf7 [<ffffffff8020f414>] do_IRQ+0x6d/0xda [<ffffffff8020caae>] ret_from_intr+0x0/0x29 ... cat /proc/interrupts: 19: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, ohci1394 22: 0 0 15 99986 IO-APIC-fasteoi ahci With one of the patches you get a failure when ohci1394 tries to obtain its IRQ, but the IRQ nobody cared is fixed: ohci1394 0000:03:07.0: PCI INT A: no GSI ohci1394: Failed to allocate interrupt 255 ohci1394: probe of 0000:03:07.0 failed with error -12 and ohci1394 cannot be loaded on that machine. It's also possible to assign ohci1394 to IRQ 22 and let the device share the IRQ with ahci. This can be seen by e.g. replacing the m2a-vm with the m2a-vm-hdmi mainboard's DSDT: cat /proc/interrupts: 19: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb6 22: 0 0 0 107 IO-APIC-fasteoi ahci, ohci1394 This works without any obvious errors, but it looks like the board should not be used that way and a kernel quirk would be even more ugly.
Created attachment 19705 [details] Original DSDT.dsl of m2a-vm BIOS
Created attachment 19706 [details] Diff between m2a-vm and m2a-vm-hdmi mainboard's DSDTs which fixes the issue Defines an IRQ for the ohci1394 device.
Created attachment 19707 [details] Conservative patch fixing the issue for the ASUS m2a-vmi and providing a boot param for others Could you please review this one also please. If this is more generally solved, I still like to add this one for SLE11 for now. Based on 2.6.27.10
Created attachment 19708 [details] General fix and Windows adoption.
irq derive is a must for pcmcia card, as pcmcia card hasn't _PRT entry and has the same irq as its pcmcia bridge. PCI spec actually defines how to do irq derive, and linux follows the spec. If you want to have a generic solution, I thought you can figure out a debug patch (not remove derive for pcmcia card) and saw if it breaks anything.
Since the box has no firewire connector, is there any reason to load the ohci1394 module? If we don't load ohci1394, I assume there's no "IRQ: nobody cared" problem. Maybe we can just prevent ohci1394 from binding to the device. I'm not sure how best to do that. One slightly hacky way would be an early PCI quirk that checks for M2A-VM DMI info and sets dev->hdr_type to something invalid so pci_setup_device() would ignore the device.
What a confusion...: This is a fixed BIOS bug. We have a m2a-vm-hdmi board, not a m2a-vm. m2a-vm-hdmi 1501 BIOS had the firewire port not configured, thus the firewire driver was using the wrong IRQ -> ahci IRQ got disabled. This got fixed between BIOS 1501 and 1701. The m2a-vm-hdmi dmi info states m2a-vm at one place, thus we thought we have a m2a-vm board. The next BIOS bug was that we could update our -hdmi board with the wrong m2a-vm BIOS (got fixed with 2201 BIOS :) ). Because the m2a-vm board does not have firewire, the wrong BIOSes again did not configure the firewire IRQ and we still saw the exactly same error -> firewire driver used wrong IRQ -> ahci breaks. Solution: Update to the correct latest BIOS and things work -> bug is invalid. Sorry for the confusion...