[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ide
Subject:    Re: [2.6.18,19] SATA boot problems (ICH6/ICH6W)
From:       Mark Lord <liml () rtr ! ca>
Date:       2007-01-31 15:30:32
Message-ID: 45C0B618.10004 () rtr ! ca
[Download RAW message or body]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]