This message is from the T13 list server.
In reading the proposal, it seems that there is a issue. Enough so the write
a proposal.
If the state does occur as the proposal describes, then the bad data is read
to clear the DRQ. A performance issue and as you comment, issue a soft reset
and re-issue the command. How long does a soft reset take (performance hit).
While the DRQ is expected, agreed clocking the data in hopes of DRQ clearing is likely to end faster than an SRST recovery. But such a host then has to avoid the livelock of clocking data forever in hopes of clearing DRQ, and also that host has to decide whether to trust the device to keep ERR set after clearing DRQ.
I think I remember most often choosing to trust the device to keep ERR set after an error, rather than choking over a device that happened to leave ERR set when raising DRQ, particularly during the C/D:I/O = x01 Command Out phase of ATAPI protocol.
Pat LaVarre http://ide-byte-counting.blog-city.com/
