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

[Mark Lord <liml@rtr.ca>]

Mark Lord wrote:
> 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?
..
> 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.

WRONG.  The qc->dma_dir turns out to be just fine (3) in this case.

And.. the messages look fine with "dmesg", but syslogd records only
the "res.." line in /var/log/messages.

Too kooky for me.