Question on RECOVERED ERROR handling
monia at am.shrmsg.shr.mts.dec.com
Tue Aug 8 13:57:03 PDT 1995
Thanks to all who responded.
In my opinion, the consensus among those who replied is expressed in John
Lohmeyer's note, which is quoted in full below. As I understand it, since the
command returning CHECK CONDITION status never began execution, the host can
recover by simply retrying this command.
Does this jibe with device implementations? I'd especially like to hear from
sequential device implementors.
John Lohmeyer wrote:
>I think it is not inconsistent to report RECOVERED ERROR sense key for a
>deferred error. The sense key pertains to the deferred error, not the
>current command. The most-recent command is not performed (and normally
>would be re-issued) no matter what the sense key is for the deferred error.
>I think the SCSI-2 wording would be clearer if we had omitted the word
>'last' from the first sentence:
>>"RECOVERED ERROR: Indicates that the last command completed
>>successfully with some recovery action performed by the
>>target. Details may be determinable by examining the
>>additional sense bytes and the information field. When
>>multiple errors occur during one command, the choice of
>>which error to report (first, last, most severe, etc.) is
>I would vote for behavior a):
>>a) The command has terminated without execution. The state
>>of the media is unchanged. For a sequential device, the host
>>must reissue the command without repositioning the media.
>John Lohmeyer E-Mail: john.lohmeyer at symbios.com
>Symbios Logic Inc. Voice: 719-573-3362
>1635 Aeroplaza Dr. Fax: 719-573-3037
>Colo Spgs, CO 80916 SCSI BBS: 719-574-0424 300--14400 baud
More information about the T10