data IU exception handling

gop at us.ibm.com gop at us.ibm.com
Fri Aug 18 09:51:33 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
Sriram,
I disagree. The reason the exception condition section was written the way
it was, was to removed target retries on IU transfers. The reason is
because, in real life, targets do not do retries (yes I know tapes do but I
see that changing in the future and this only applies to packetized). For
backward compatibility reasons we cannot change the retry option on data
group transfers but that is not an issue in packietized. So we made it
simpler and removed (except for the conflict you found) the retry option in
packetized.

Bye for now,
George Penokie

Dept Z9V  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880



Sriram Srinivasan <srirams at lsil.com> on 08/18/2000 11:25:16 AM

Please respond to Sriram Srinivasan <srirams at lsil.com>

To:   George Penokie/Rochester/IBM at IBMUS
cc:   t10 at t10.org
Subject:  Re: data IU exception handling




George:

   I'd suggest that we allow retires for the target.  I base my argument on
the
following (from SPI-4 rev0):

   1) In 10.8.3.3.7 and 10.8.3.3.6 (data group transfers) the last
paragraphs
allow retries.  "If the target does not retry transferring the information
transfer it or exhausts its retry limit the target shall ...".  Y should
this be
different between data group transfers and IU transfers?

   2) IU transfers already mandate an implied save data pointers (after the
initiator receives the data IU) and restore pointers (after the initiator
gets a
SPI L_Q).  So it'be great to retry just the IU in error by allowing the
target
to send the MODIFY DATA POINTER message instead of mandating that the
target
SHALL do the CHECK CONDITION, ABORTED COMMAND sense key etc.

   Based on these, I'd suggest the following change(s) be made in SPI-4:

   paragraph 4 of 10.8.3.3.3:
   "If the information unit that failed was not a SPI status information
unit
and the message received from the initiator was an INITIATOR DETECTED ERROR
message then the target <MAY> retry the task associated with the received
INITTIATOR DETECTED ERROR message.  If the target retries the operation, it
<SHALL> send a MODIFY DATA POINTERS message then request that the SPI data
information unit be transferred again.  If the target does not retry the
operation or it exhausts its retry limit, the target <SHALL> send a SPI
L_Q/SPI
status information unit pair to the initiator with a CHECK CONDITION status
and
a sense key set to ABORTED COMMAND and an additional sense code set to
INITIATOR
DETECTED ERROR MESSAGE RECEIVED for the task associated with the received
INITTIATOR DETECTED ERROR message."

   paragraph 2 of 10.8.3.3.4:

   "If the nexus has been fully identified (i.e., an I_T_L_Q nexus has been
established) and the target detects an iuCRC error in any SPI information
unit
it receives while in the DT DATA OUT phase the target <MAY> retry the task
associated with the iuCRC error. If the target retries the operation, it
<SHALL>
send a MODIFY DATA POINTERS message then request that the SPI data
information
unit be transferred again.  If the target does not retry the operation or
it
exhausts its retry limit, the target <SHALL>, <<BEFORE RECEIVING ANOTHER
SPI
DATA INFORMATION UNIT OR DATA STREAM INFORMATION UNIT IN DT DATA OUT
PHASE>>,
switch to a DT DATA IN phase and send a SPI L_Q/SPI status information unit
pair
to the initiator with a CHECK CONDITION status and a sense key set to
ABORTED
COMMAND and an additional sense code set to iuCRC ERROR DETECTED for the
task
associated with the iuCRC error"

   The reason I added the "<<BEFORE RECEIVING ...>>" lines was because the
original wording "before receiving another SPI L_Q information unit" can
only
happen if u are talking about receiving SPI L_Qs before command IUs and
does not
apply to write transfers where the target sends the SPI L_Qs.

   Are there any other reasons to not allow the target from doing retries
in IU
transfers?

   Sriram

>
>Sriram,
>You are correct, the is a conflict between those two sections. The error
>handling was added in some time after the wording about retries being
>allowed. I suggest the sentence:
>'If a target retries an operation it shall send a MODIFY DATA POINTERS
>message then request that the SPI data information unit be transferred
>again. '
>be deleted.
>John, This should be placed on the agenda for the SPI-4 meeting next week.
>
>Bye for now,
>George Penokie
>
>Dept Z9V  114-2 N212
>E-Mail:    gop at us.ibm.com
>Internal:  553-5208
>External: 507-253-5208   FAX: 507-253-2880
>
>
>
>Sriram Srinivasan <srirams at lsil.com> on 08/17/2000 05:24:28 PM
>
>Please respond to Sriram Srinivasan <srirams at lsil.com>
>
>To:   t10 at t10.org
>cc:
>Subject:  data IU exception handling
>
>
>
>
>* From the T10 Reflector (t10 at t10.org), posted by:
>* Sriram Srinivasan <srirams at lsil.com>
>*
>   I have a question on data IU exception handling:
>
>   In 10.8.3.3.3 (SPI4-rev0) paragraph 4 it states:
>
>   "If the information unit that failed was not a SPI status information
>unit
>and the message received from the initiator was an INITIATOR DETECTED
ERROR
>message then the target <SHALL> send a SPI L_Q/SPI status information unit
>pair
>to the initiator with a CHECK CONDITION status and a sense key set to
>ABORTED
>COMMAND and ..."
>
>   Paragraph 6 of 14.1 states:
>
>   "The initiator shall save the data pointers as soon as the last byte of
>the
>last iuCRC for a SPI information unit is transferred.  The save <SHALL>
>occur
>even if the initiator detects an error in the SPI data information unit.
>If a
>target retries an operation it <SHALL> send a MODIFY DATA POINTERS message
>then
>request that the SPI data information unit be transferred again."
>
>   Doesn't the first one (para 4 in 10.8.3.3.3) say that tha target cannot
>retry
>the command ('coz he sent the ABORTED COMMAND sense key)?  In this case,
>the
>initiator would probably resend the whole command again.  But para. 6 of
>14.1
>seems to imply that targets can retry the SPI data IU and mandates that
the
>MODIFY DATA POINTES message be sent prior to such a retry.  These seem to
>contradict each other.  The same wordings are present in SPI-3 as well.
>
>  Is there a bigger thing that I'm missing here?  Please let me know.
>
>  Thanx,
>  Sriram
>
>----------------------------------------------------------------------
>
> Sriram Srinivasan                       Sriram.Srinivasan at lsil.com
> ASIC Design Engineer, LSI Logic,
> 2001 Danfield Ct.,                      Phone: 970-206-5847
> Fort Collins, CO 80525                  FAX  : 970-206-5244
>----------------------------------------------------------------------
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Sriram Srinivasan,   |  hain aur bhi duniya me sukhanvar bahut ach-che,
 ASIC Design Engineer, |  kehte hain ki 'ghalib' ka hai andaaz-e-bayaan aur
     LSI Logic,            |
  2001 Danfield Ct.,   |  Meaning in English
Ft. Collins, CO 80525  |  ------------------
Phone : (970) 206 5847 |  There are a lot of good poets in the world,
FAX   : (970) 206 5244 |  But they say that Ghalib's descriptions are
                       |                                   a class apart




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list