Re: libata fails to recover from HSM violation involving DRQ status

[Mark Lord <liml@rtr.ca>]

Mark Lord wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>>> So, this is specific to SATA (the host side at least) piix && PIO READ,
>>> right?  I think we can fit this code nicely into
>>> piix_sata_error_handler() if we make sure that it triggers under the
>>> right condition - after a PIO READ command fails due to HSM violation
>>> caused by stuck DRQ.
>>
>> Yeah, so far it's just PIO FROM DEVICE on a "SATA" device on ata_piix.
>> It *may* be more widespread than that, but we'll have to test some 
>> others.
> 
> I retested this again today on my new pure-SATA notebook with ata_piix.
> In this case, the DRQ drain is not necessary, but also doesn't harm 
> anything.
> Tested it both ways.  This is with a Hitachi HTS541612J9SA00 SATA drive.
> 
> The original fault was on ata_piix SATA, with some kind of external
> bridge (on the motherboard) to a Seagate PATA drive.  Sometime in the
> next few days I'll have the exact same drive, but with a SATA interface,
> and we'll try that in the pure-SATA situation.
> 
> This will tell us whether it's the bridge, or the drive, that was the 
> issue.
> 
> The fix remains the same: drain the data fifo when DRQ is left high.

Okay, I finally got round to testing this with the new pure-SATA
notebook I have here.  Same problem:  without draining the DRQ fifo,
the system *never* recovers.

But with the patch to drain DRQ, all is well.  That patch is now a keeper
for my own kernels.  Tejun, did you want to cook up a better-placed variant
of it for mainline?  I'm away for a few days now..

Cheers