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

[Jeff Garzik <jeff@garzik.org>]

Mark Lord wrote:
> Tejun,
> 
> While working on the new hdparm (version 7.0, released today),
> I ran into trouble when a buggy SG_IO/ATA_16 packet caused
> the libata EH to get confused.
> 
> I triggered this by accident, issuing an IDENTIFY command
> which incorrectly specified ATA_PROT_NODATA.  My error, for sure,
> but libata never recovered from the "stuck DRQ bit" that resulted.
> 
> In the IDE driver, we had code to try and cope with stuck DRQ,
> by just looping and reading from the data port a few times.
> That could have been done better, but it worked a lot of the time,
> back in those simpler days.
> 
> I don't know what you try in libata-eh, but perhaps it can be tweaked?
> Below is the 'dmesg' from that system before I hit the big red button.

I am reluctant to do anything about this.

All manner of things can go wrong, if the taskfile protocol specified 
disagrees with the taskfile contents.

At that point you are in undefined territory, since libata will happily 
ARM a DMA controller or otherwise program controller registers in 
preparation for the requested taskfile protocol.  Data corruption, hard 
locks, anything could happen at that point.

Maybe we do need to recover from a stuck DRQ bit, but I'll wait until 
that symptom shows up with a different catalyst.

	Jeff