http://bugzilla.kernel.org/show_bug.cgi?id=12382
Summary: Asus M2A-VM shows IRQ nobody cared due to wrongly derived IRQ from PCI bridge Product: ACPI Version: 2.5 KernelVersion: Probably all which are ACPI capable Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Config-Interrupts AssignedTo: acpi_config-interru...@kernel-bugs.osdl.org ReportedBy: tr...@suse.de CC: len.br...@intel.com, shaohua...@intel.com, jbar...@virtuousgeek.org, t...@kernel.org 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. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla