SCSI-2 Parity Errors -Reply

Lawrence Chen lchen at pyramid.com
Thu Mar 16 10:23:47 PST 1995


On Mar 16, 11:58am, "Miller, Jim" wrote:
> Subject: 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.
> 
I agree that hosts should be told when parity errors occur. This means 
that a check condition and Sense data is most appropriate. Dropping the 
bus does not provide the appropriate info to the host and fancy retry ops 
are not desired.

-Larry

>           Jim Miller
> 
> 
> 
> 
>  ----------
> 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
> 
> 
>-- End of excerpt from "Miller, Jim"



-- 
-- 
--
       -m-------  Lawrence Chen           Pyramid Technology Corporation
     ---mmm-----  lchen at pyramid.com       3860 North First Street
   -----mmmmm---  VOICE: (408) 428-8974   Mail Stop SJ2-2-30
 -------mmmmmmm-  FAX:   (408) 428-7260   San Jose, CA 95134-1702
-- End of excerpt from Lawrence Chen
--
--
-- And something to think about ...
--
Misery loves company, but company does not reciprocate.




More information about the T10 mailing list