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