SCSI-2 Parity Errors -R
jmcgrath at qntm.com
Thu Mar 16 10:36:09 PST 1995
Reply to: RE>>SCSI-2 Parity Errors -Reply
>In reguards to doing tricky things with parity errors - I would recommend
>that the drive immediately report any and all parity errors. If there are
>parity errors being detected, then a 2 bit error could also occur and this
> would go undetected. This could cause the drive to go to the wrong address
>if it occurred in the CDB phase or have undetectable data corruption if it
>occurred in the Data phase. Why risk it?!! Any detection of a parity
>error should be a RED FLAG that you have bus integrity problems that need
>to be resolve quickly. The resolution could be as simple as proper
>termination or termination power. Some drives will correct a parity error
>(primarily in the Message phase) and not tell the host. Even if it did
>successfully detect the error I feel the host should be notified.
> Jim Miller
Note that if parity error are occuring than they should also be visiable to
the host when information is sent by the drive to the host. While I do
not object to detection reporting as much as error recovery, it still does
not seem to be really needed (and thus best kept away from in the best of
From: Steve Owen
Subject: Re: SCSI-2 Parity Errors -Reply
Date: Thursday, March 16, 1995 11:31AM
Reply to: RE>>SCSI-2 Parity Errors
My advice to host people is always to assume the worse and prevent the drive
doing anything tricky. Specifically, reject any
MODIFY DATA POINTERS or RESTORE POINTERS, and in general just about the
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
is simply not worth the debugging and reliability problems you get in using
complicated error recovery protocol rather than just killing the command at
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
initiator must then resend the entire message that has the parity error.
this is all MANDATORY.
Since support of recovery from parity errors in the Message phases is
don't see the point of not allowing recovery from parity errors in the
As far as parity errors detected by the target in the Command or Data Out
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
Restore Pointers. Your approach would require that an initiator reject all
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"
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
Steve Owen owens at wasc.egginc.com
More information about the T10