Question on RECOVERED ERROR handling

Charles Monia monia at am.shrmsg.shr.mts.dec.com
Tue Aug 8 13:57:03 PDT 1995


Hi:

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.


Thanks,

Charles




John Lohmeyer wrote:
===============================
>
>Charles,
>
>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
>>device specific."
>
>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.
>
>Regards,
>
>John
> --
>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 mailing list