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

[Mark Lord <liml@rtr.ca>]

Tejun Heo wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>> ###### Test stuck DRQ on VIA-sata (disk):
>>>
>>> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
>>> ata1.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb 0x0 data 0
>>>         res 58/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
>> Why do we not always put a '\n' in front of that last line above ??
>> Sometimes it seems to have it, and lots of times it does not have a '\n'.
>> Weird.
>>
>>> ###### Test stuck DRQ on VIA-pata (ATAPI DVD/RW):
>>> ###### Notice how the first "ata4.00: cmd ..." line is *missing*:
>>>
>>>         res 58/00:02:00:00:02/00:00:00:00:00/40 Emask 0x2 (HSM violation)
>>> ata4: soft resetting port
>>> ata4.00: configured for UDMA/66
>>> ata4: EH complete
>> And in this case, the first line of diagnostics (the "cmd" line)
>> is always missing.  Why?
> 
> Hmmm... that's very weird.  I've never seen such problems. 

Well, from looking at the code, we see that the last thing
before the "res" line is a "%s" for dma_str[qc->dma_dir].
If qc->dma_dir is corrupted (or just not set), then we'll get
semi-random garbage, which must be what's happening here.

The easy fix is to do this:

-                        dma_str[qc->dma_dir],
+                        dma_str[qc->dma_dir & 3],

We should do that regardless, as it's just safe programming.

Tejun:  I don't have an up-to-date GIT tree here at the moment,
so perhaps you could generate a patch to put this fix into your tree for Jeff ?

I'll try and test it here first, and post again after I've done so.

Secondly, I might later have a look and see why qc-dma_dir
doesn't have a proper value..

Thanks