SCSI-2 Parity Errors -R

Jim McGrath jmcgrath at
Thu Mar 16 09:15:03 PST 1995

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

>>My advice to host people is always to assume the worse and prevent the
>>drive from doing anything tricky.  Specifically, reject any
>>just about the command (if the drive does not beat you to it

>>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.



>I'm not sure I agree with this approach. Support of the Message Parity Error
>is mandatory for both SCSI-2 intiators and targets. If the target sends a
>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.

That is incorrect.  First, the target need never send a MESSAGE PARITY ERROR
message -
while it is mandatory to support it, when to sent it is a vendor unique drive
decision -
nothing in the standard requires the drive to send it in a parity error state.
the standard allows other responses, including going immediately to the BUS
FREE state.

Second, if the host receives that message then it is perfectly free at that
point to send
an ABORT message to the device.  This is perfectly legal, and given the
manner in which message error recovery is implemented (e.g. if the previously
messages were a mixture of garbled and non-garbled ones, did the non-garbled
already execute?  who knows), is the safest thing for the host.  The host is
obligated to repeat a previous action in SCSI, simply because higher priority
occuring later in time might have totally eliminated the need for the previous

>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.

Once again, incorrect.  Support of a message does not mean support of a
error recovery technique.

>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
>Pointers messages from the target regardless of their underlying purpose.

There is no good reason for the drive to ever send a RESTORE POINTERs message.
 I would
never allow our drives to do that.  I am absolutely certain that many hosts do
not do
"proper" data pointer management, and my first obligation as device
manufacturer is not
to screw up my customers (unless of course they specifically request it).

>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
>controls which bus phase comes next, the target gets to decide how to recover
|from the

True, but as pointed out earlier, the host can ALWAYS abort the IO (or for
matter BUS DEVICE RESET the device).

If I had my way, I would outlaw all of these fancy, seldom used, full of bugs
recovery techniques (a SIP topic for sure).


More information about the T10 mailing list