SCSI-2 Parity Errors -Reply

Witalka, Jerome J [RV] jjw1 at PO9.RV.unisys.com
Thu Mar 16 10:22:00 PST 1995


I don't agree with your response.  Recovery from Message parity errors and 
Recovery from data phase parity errors are separate issues.  You are correct 
in that Message Parity Error support is required by SCSI 2 (an unfortunate 
decision in my view).  However, support of Modify Data Pointers is optional 
and in our systems almost impossible to implement.  We allow our Host 
software to supply us with an unlimited link list of main storage data 
buffers.  (For those of you familiar with the IBM BMC architecture, this is 
called Data chaining).  It would be almost impossible to back up through 
this change by an arbitrary amount specified in the Modify Data Pointers 
message.

Secondly, as the Target is not in control of the recovery procedure as the 
Initiator is free to reject the message.  My biggest complaint of the SCSI 
interface is that it put control at the wrong end of the cable.  Hosts have 
more information available about system characteristics than Targets and 
with the programmability of Host software can more often develop better 
error recovery routines.  I still remember a disk subsystem we had that 
insisted on trying multiple head bumps 15 times each to re- read Data (with 
the rev slip for each retry) in a misguided error recovery routine that 
locked system access to the rest of the data until it finally finished.  If 
Targets insist on implementing elaborate recovery routine, they should at 
least give the host the ability to disable them..

The most time consuming and schedule destroying part of system debug is the 
area of error recovery.  Back in  the bad old days when peripheral failure 
rates were relatively high, complicated error recovery  may have had its 
place.  In today's environment, errors occur so infrequently that the 
simplest procedure that works, even though it may be slower, with a few 
exceptions is the best policy.

By the way, just terminating the IO and restarting from scratch has the 
added benefit of allowing any transient conditions that may have caused the 
Bus parity error to die off by retry time.  If the error wasn't transient, 
it doesn't really mater which recovery routine is used.
Jerry Witalka  M.S. 4873                 EMail:jjw1 at po9.rv.unisys.com
Unisys Corporation                          Voice:  612-635-7958
P.O. Box 64942
 St. Paul, MN 55164-094
 ----------
>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