Packetized L_Q IU type field changes

gop at us.ibm.com gop at us.ibm.com
Wed Dec 15 15:48:37 PST 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
Richard,
If there is an iu interval (which there never would be for L_Q IUs coming
into the target) then it should be honored and the iuCRC bit bucketed with
the reset of the bits. This is the same behavior that is required if a
iuCRC error occurred in the middle of a data IU transfer. (i.e., the
receiving SCSI device is required to bit bucket all the remaining bytes,
including any iuCRCs, in the failed IU.)

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



Richard Moore <r_moore at qlc.com> on 12/15/99 04:58:16 PM

To:   George Penokie/Rochester/IBM at IBMUS, t10 at t10.org
cc:
Subject:  RE: Packetized L_Q IU type field changes




>2)There is no wording that tells what to do in the case where
>an invalid
>type code is sent to a target (This would be another test case
>that would
>be tried by our tester friends). I have two suggestions as to
>what should
>be the response and we need to pick one:
>
>-Bring out the big hammer and go bus free.

Easy for a target to do. On the other hand, if the invalid type is sent
from
a target to an initiator, what should the initiator do? I don't find this
case covered by "DT DATA IN phase information unit transfer exception
condition
handling" (10.8.3.3.3), which only seems to deal with iuCRC errors. I
suggest
changing the wording in the last paragraph from "detects an iuCRC error" to
"detects an invalid TYPE field or an iuCRC error". The target case you
describe
could be handled similarly by changing the last paragraph of 10.8.3.3.4 in
the
same way.

>-Bring out the little hammer and, after dumping all the bytes for the
>unidentified IU the follows the L_Q IU (remember in this case
>the iuCRC is
>good so there is a valid length in the L_Q IU and the target is still
>required to transfer that number of bytes before doing
>anything else except
>bus free) the target would change to the DT DATA IN phase and
>send a L_Q
>IU/Status IU with the RSPVALID bit set and the packetized
>failure code set
>to 02h (or a newly defined code). If we use the 02h it's
>definition would
>have to be changed from 'SPI command information unit fields
>invalid' to
>'SPI command or SPI L_Q fields invalid'. Or we define a new
>code xxh that
>would be defined as SPI L_Q information unit fields invalid.

This sounds OK at first glance, but is the IUCRC INTERVAL observed or
ignored
in this case? We need to be specific on this point if we are going to
bit-bucket
the following information unit, since we need to know the exact size of the
information unit that will be bit-bucketed. Note we are already forced to
assume
that the DATA LENGTH field is valid, so there is probably no harm in making
the
further assumption that the IUCRC INTERVAL is valid.

 -- Richard Moore
    QLogic Corp.



*
* 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