SCSI-2 Parity Errors -R

Jim McGrath 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
KISS traditions).

Jim


 ----------
From: Steve Owen
To: scsi
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
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