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

[Tejun Heo <htejun@gmail.com>]

Mark Lord wrote:
> Jeff Garzik wrote:
>>
>> It's not really a good idea for SATA.  The "FIFO" often co-emulated by
>> the SATA controller and SATA phy.  You just want to kick SATA really
>> hard (i.e. bus reset and friends).
> 
> Sure.  So why don't we do that now?

We do that.  It's just that ata_piix is lacking SControl access so all
we can do is SRST not PHY hardreset.  I don't think draining
FIFO/whatever on most SATA controllers would be unnecessary as PHY
hardreset would make most drives forget what they were doing.  I thought
SRST would have similar effect.  It's supposed to reset the device's HSM
and thus clear DRQ, right?  Stuck DRQ after SRST seems odd to me.

One more thing to note is that there might be no way to drain data
safely on non-SFF (ahci/sil24...) interfaces and some controllers lock
the machine up hard when TF registers are accessed in certain unexpected
way (unsurprisingly, sata_nv), so if we do this, it needs to be
configurable per-driver.  Another question is how would SATA controllers
emulating TF interface react when data port is polled after a DMA
command.  I'm pretty sure many of them would behave erratically.

Anyways, can you try to hack it into ata_bmdma_error_handler() and see
whether it actually works?  You can check for AC_ERR_HSM there and drain
data port if DRQ is set.  After HSM, ATA_NIEN is set and the port should
be quiescent at that point.

Thanks.

-- 
tejun