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

[Tejun Heo <htejun@gmail.com>]

Mark Lord wrote:
>>>> Ah.. one more thing, is this draining also needed after DMA commands or
>>>> only after PIO commands?
>>
>> My drive doesn't do IDENTIFY_DMA, so I fed it a READ_DMA instead
>> with "no data", and libata recovered without draining. 
> 
> More specifically, here's what happens for READ_DMA(1 sector)
> with "NON_DATA" specified (same circustances as the failed IDENTIFY):
> 
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:01:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
>         res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
> ata1: port is slow to respond, please be patient (Status 0xd0)
> ata1: port failed to respond (30 secs, Status 0xd0)
> ata1: soft resetting port
> ATA: abnormal status 0xD0 on port 0x000101f7
> ATA: abnormal status 0xD0 on port 0x000101f7
> ata1.00: configured for UDMA/100
> ata1: EH complete
> SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> 
> So no draining, and all is well again.
> Odds look pretty good that this is just a PIO thing.

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.

Can you please perform similar test on a native PATA device connected to
native PATA controller?  I'm curious whether SRST makes real silicons
forget about the on-going command.

Thanks.

-- 
tejun