Re: [2.6.18,19] SATA boot problems (ICH6/ICH6W)

[Mark Lord <liml@rtr.ca>]

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Alan wrote:
>>>> Some SATA controllers use 0xff to indicate empty port.  This seldomly
>>>> matters as we have the almighty SStatus register to check device
>>>> presence (there is a bug regarding this, patch pending).
>>>>
>>>> This GoVault drive fails because ata_piix doesn't have SCR while using
>>>> 0xff to indicate port not ready (dunno exact which state causes 0xff
>>>> status tho) while the GoVault drive fails to clear that state in 150ms
>>>> (not 30s).  The libata sees 0xff after SRST if GoVault drive is 
>>>> attached
>>> So we can also cut this down by only doing the extra polling on a device
>>> which is SATA and lacks SCR ?
>>
>> That's true but the offending one is ata_piix, so the cutting down is
>> not as effective.  If we can live with the extra two secs per empty port
..
> While I don't mind making changes for this device, and taking into 
> consideration Alan's recent comments that some ATAPI workarounds are 
> still yet to appear for libata, I still dislike making changes for one 
> specific device with non-standard behavior.

How does drivers/ide manage with this device, or does it?
It would be useful here to patch the PCI ID into drivers/ide
for that PIIX variant, and try it.. just to see what the
behaviour is.

There are other possible ways to avoid a 2-second per-port delay at boot.
Eg. by attempting write+readback on some of the other registers.

It all sounds very messy, but that's the ATA/ATAPI world.

Cheers