[Bugme-new] [Bug 12382] New: Asus M2A-VM shows IRQ nobody cared due to wrongly derived IRQ from PCI bridge

Wed Jan 7 14:56:44 PST 2009

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-interrupts at kernel-bugs.osdl.org
        ReportedBy: trenn at suse.de
                CC: len.brown at intel.com, shaohua.li at intel.com,
                    jbarnes at virtuousgeek.org, tj at 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 on the CC list for the bug, or are watching someone who is.