Re: [bug] sata detection problem

Ingo Molnar
2009-02-11T15:25:59Z

* Tejun Heo <htejun@gmail.com> wrote:

> Hello,
>
> Ingo Molnar wrote:
> > Hm, in a boot test i had this boot failure:
> >
> > [ 15.504053] calling piix_init+0x0/0x30 @ 1
> > [ 15.508050] ata_piix 0000:00:1f.1: version 2.12
> > [ 15.516193] ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
> > [ 15.520029] ata_piix 0000:00:1f.1: PCI INT A -> Link[LNKG] -> GSI 11 (level, low) -> IRQ 11
> > [ 15.524072] ata_piix 0000:00:1f.1: setting latency timer to 64
> > [ 15.528115] scsi0 : ata_piix
> > [ 15.531526] scsi1 : ata_piix
> > [ 15.544044] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
> > [ 15.548028] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
> > [ 15.716358] ata1.00: ATAPI: ýVýVýVýVýVýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý, ý\x19ýVýVýV, max UDMA7
> > [ 15.720044] ata1.00: limited to UDMA/33 due to 40-wire cable
> > [ 15.740296] ata1.00: configured for UDMA/33
>
> That's one strange ghost device detection. Because PATA doesn't have
> a reliable way of determining device presence, libata uses combination
> of tests along the probing sequence to determine device presence.
> Each test is intentionally made somewhat relaxed to avoid missing a
> present device (and those condition often do trigger). It seems
> somehow it is passing all the existing tests. The hardest part
> probably is the IDENTIFY command sequence but for SFF controllers it's
> done via polling instead of IRQ and thus by having the right (or
> wrong) status register value a port with floating pins may be able to
> pass it.
>
> How reproducible is the problem? It can probably be worked around by
> making the NODEV_HINT checking a tad bit tighter in SFF host state
> machine. PATA device presence detection is an art not an exact
> science. :-)

it's very sporadic - out of thousands of bootups this is the first time :-/

Ingo