Re: [bug] sata detection problem

[Ingo Molnar <mingo@elte.hu>]

* 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