SCSI-2 Parity Errors -Reply

Steve Owen owens at wasc.egginc.com
Thu Mar 16 08:31:39 PST 1995


>>>>>>>>>>>>>>>
        Reply to:   RE>>SCSI-2 Parity Errors


My advice to host people is always to assume the worse and prevent the drive from
doing anything tricky.  Specifically, reject any
MODIFY DATA POINTERS or RESTORE POINTERS, and in general just about the command (if
the drive does not beat you to it with a CHECK CONDITION).

Parity errors should not occur often (if they do, you are in big trouble anyway).  It
is simply not worth the debugging and reliability problems you get in using a
complicated error recovery protocol rather than just killing the command at that point
and starting over.

Jim



<<<<<<<<<<<<<<<

I'm not sure I agree with this approach. Support of the Message Parity Error message
is mandatory for both SCSI-2 intiators and targets. If the target sends a Message
Parity Error to the initiator and switches immediately to the Message In phase, the
initiator must then resend the entire message that has the parity error. Remember that
this is all MANDATORY.

Since  support of recovery from parity errors in the Message phases is mandatory, I
don't see the point of not allowing recovery from parity errors in the Command and
Data phases.

As far as parity errors detected by the target in the Command or Data Out phases, if
the target trys to recover from the error with a Restore Pointers, the initator has no
idea that a parity error occurred. It only knows that the target wants to perform a
Restore Pointers. Your approach would require that an initiator reject all Restore
Pointers messages from the target regardless of their underlying purpose.

It is also important to remember the initiator is not in the "driver's seat" when a
target detects a parity error. The target detected the error and since the target
controls which bus phase comes next, the target gets to decide how to recover from the
error.

Steve Owen    owens at wasc.egginc.com 
EG&G  WASC





More information about the T10 mailing list