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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
