Messages in this thread | | | Subject | Re: libata Promise driver regression 2.6.5->2.6.6 | From | Len Brown <> | Date | 17 May 2004 15:01:59 -0400 |
| |
On Sun, 2004-05-16 at 13:49, Sergey Vlasov wrote: > On Sun, 16 May 2004 21:18:48 +0400, Brad Campbell wrote: > > > I have been using 2.6.5 happily for a while now on this machine. > > It's an Asus A7V600 with 3 Promise SATA150-TX4 SATA cards. > > > > With 2.6.6 (and 2.6.6-bk3) it hangs with a dma timeout on boot > detecting the 9th sata drive (there > > are 10). I left it for about 10 minutes to see if anything else > transpired but it just sat there. > > I'm on a serial console to this machine at the moment and I could > not get it to respond to the magic > > sysrq key over serial either. > > > > I have placed all relevant info including a capture of 2.6.5 boot > and 2.6.6 boot, plus all requested > > info from linux/REPORTING-BUGS on my webpage > > > > Normal working dmesg > > http://www.wasp.net.au/~brad/2.6.5.log > > > > Hung up dmesg > > http://www.wasp.net.au/~brad/2.6.6.log > > > > .config and all other info I could gather. > > http://www.wasp.net.au/~brad/2.6.6.config > > Much as I'd love to be subscribed, I just can't keep up with the > volume so please cc: me. > > Willing to try patches/hacks/suggestions > > Looks like ACPI problems. First, for some reason ACPI in 2.6.6 > decided to > use PIC mode, while 2.6.5 used IOAPIC mode.
This is because the 2.6.6 .config did not include IOAPIC support.
> Second, IRQ 12 was chosen for > the Promise controller which failed; this is a known problem in 2.6.6, > the patch at http://bugzilla.kernel.org/show_bug.cgi?id=2665 should > fix it.
Yes, this is going to be a problem:
ata9: SATA max UDMA/133 cmd 0xE080E200 ctl 0xE080E238 bmdma 0x0 irq 12 ata10: SATA max UDMA/133 cmd 0xE080E280 ctl 0xE080E2B8 bmdma 0x0 irq 12 ata11: SATA max UDMA/133 cmd 0xE080E300 ctl 0xE080E338 bmdma 0x0 irq 12 ata12: SATA max UDMA/133 cmd 0xE080E380 ctl 0xE080E3B8 bmdma 0x0 irq 12
But it isn't caused by bug 2665.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 *12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 *9 10 11 12) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12) *15, disabled. ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) SCSI subsystem initialized ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 12 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5 ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 9 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 9 ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
LNKH would have hit the bug fixed in 2665. However, LNKH isn't enabled, so we don't hit that bug.
LNKC, OTOH, is already enabled on IRQ12; and both 2.6.5 and 2.6.6 will leave it there unless you explicity tell Linux to move IRQs in PIC mode with "acpi_irq_balance".
apples/apples comparison would be to boot your 2.6.5 kernel with "noapic". I expect 2.6.5 will have the same issue with IRQ12 in PIC mode. Unusual for a BIOS to put PCI devices on IRQ12 like that...
-Len
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |