http://bugzilla.kernel.org/show_bug.cgi?id=9346
------- Comment #2 from [EMAIL PROTECTED] 2007-11-19 23:14 -------
The ACPI interrupt routing on this board is simple.
in IOAPIC mode, all the wires are hard-coded.
So if we're getting the wrong IRQ for the device, then
it means we'd have to be confused about the pci seg/bus/fun
or something, because the pci-device->irq mapping is constant.
What did /proc/interrupts look like with working 2.6.23
and what do they look like with 2.6.24?
Do you see the same failure with acpi=off?
from the dmesg:
ata9.00: qc timeout (cmd 0xa0)
...
which is this guy (this is the 1st system i've seen reporting 11 ata
controllerrs)
ata9: PATA max UDMA/100 cmd 0xc000 ctl 0xc100 bmdma 0xc400 irq 17
ata9.00: ATAPI: BENQ DVD DD DW1640, BSRB, max UDMA/33
ata9.00: configured for UDMA/33
we have some sharing on IRQ 17
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 17 (level, low) -> IRQ 17
Curiously, the lspci shows the controller at a different pci-id --
maybe there is some magic going on with the pci ids?
04:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI
Controller (rev 02) (prog-if 85 [Master SecO PriO])
Interrupt: pin B routed to IRQ 17
--
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.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
