Re: hdc: lost interrupt ide-cd: cmd 0x3 timed out ...

[Len Brown <len.brown@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

Bob,
thanks for the info.
The BIOS on this box has a bug where it is reporting a current
IRQ to be outside the list of possible IRQs:

ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 14 15) *9

It then references this with pinA of device 9:

Package (0x04) { 0x0009FFFF, 0x00, \_SB.PCI0.LNKB, 0x00 },

which is
00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev
07)

In the past, we'd enable this on IRQ9, even thought it is illegal.

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 9

But we found that broke some boxes.

So, now we choose an IRQ from the possible list, preferring
the highest interrupt number in the list -- 15.
Didn't see it in your .JPG dmesg, but I expect this was there:

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 15

and probably that set IRQ15 to level/low which killed IDE.

Please try the attached patch which disables the sanity
check above.

Also might be interesting to see what happens on this system
if it is booted (without the patch) with "acpi_irq_balance"

thanks,
-Len


[-- Attachment #2: sis-debug.patch --]
[-- Type: text/plain, Size: 435 bytes --]

===== drivers/acpi/pci_link.c 1.28 vs edited =====
--- 1.28/drivers/acpi/pci_link.c	Thu May  6 16:03:17 2004
+++ edited/drivers/acpi/pci_link.c	Sun May  9 21:57:39 2004
@@ -549,7 +549,7 @@
 	/*
 	 * if active found, use it; else pick entry from end of possible list.
 	 */
-	if (i != link->irq.possible_count) {
+	if (link->irq.active) {
 		irq = link->irq.active;
 	} else {
 		irq = link->irq.possible[link->irq.possible_count - 1];