CHECK CONDITION for an SRR FC-4 Link Service Reject

John Tyndall jtyndall at crossroads.com
Tue Dec 4 06:59:39 PST 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "John Tyndall" <jtyndall at Crossroads.com>
*
I believe Dave is saying basically the same thing I did. The only caveat
I was attempting to add was that if the LS_RJT occurs on an SRR
requesting a data phase retransmission and the FCP_RSP has already been
sent, it may be impossible to modify the FCP_RSP. Of course, if the
initiator is requesting a re-transmission of the FCP_RSP there is an
opportunity to change the response, as Dave indicated.

John Tyndall
Architect
Crossroads Systems Inc.
Email  : jtyndall at crossroads.com
Phone : 512-928-7282


-----Original Message-----
From: Dave Peterson [mailto:dap at cisco.com]
Sent: Monday, December 03, 2001 12:41 PM
To: Kevin D Butt; John Tyndall; t10 at t10.org; Paul.A.Suhler at seagate.com
Subject: RE: CHECK CONDITION for an SRR FC-4 Link Service Reject


If the target returns an LS_RJT in response to an SRR, the associated
FCP_RSP IU for the command returns a CHECK CONDITION with an ASC of
INITIATOR DETECTED ERROR MESSAGE RECEIVED. This would be true even for
the
case where the initiator is requesting the FCP_RSP be retransmitted and
the
FCP_RSP the target originally sent contained GOOD status (for example).
An FCP_RSP cannot be returned via an LS_RJT and there is no deferred
error
condition.

Dave

> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Kevin D
> Butt
> Sent: Monday, December 03, 2001 9:36 AM
> To: John Tyndall; t10 at t10.org; Paul.A.Suhler at seagate.com
> Subject: RE: CHECK CONDITION for an SRR FC-4 Link Service Reject
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Kevin D Butt" <kdbutt at us.ibm.com>
> *
>
> John & Paul,
>
> I've received two responses now.  These two responses conflict with
each
> other.  Is there anybody else that can join in and agree or disagree
with
> either of the responses?
>
> Thanks,
>
> Kevin D. Butt
> IBM Tape Products
> SCSI and Fibre Channel Microcode Development
> 6TYA, 9032 S. Rita Rd.
> Tucson, AZ  85744
> Office:  (520)799-5280, Tie-line 321
> Lab: (520)799-2869
> Fax:  (520)799-4062
> Email:  kdbutt at us.ibm.com
>
>
>
>
>
>                       "John Tyndall"
>
>
>                       <jtyndall at crossro        To:       Kevin D
> Butt/Tucson/IBM at IBMUS, <t10 at t10.org>
>
>                       ads.com>                 cc:
>
>
>                       Sent by:                 Subject:  RE:
> CHECK CONDITION for an SRR FC-4 Link Service Reject
>
>                       owner-t10 at t10.org
>
>
>
>
>
>
>
>
>                       11/29/2001 12:45
>
>
>                       PM
>
>
>
>
>
>
>
>
>
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "John Tyndall" <jtyndall at Crossroads.com>
> *
> I read this to mean that if an SRR is received that can not be
satisfied
> and the status has not yet been transmitted then the status should be
> changed as specified to indicate that an error has occurred. It is
> somewhat analogous to an initiator detected parity error in parallel
> SCSI.
>
> John Tyndall
> Architect
> Crossroads Systems Inc.
> Email  : jtyndall at crossroads.com
> Phone : 512-928-7282
>
>
> -----Original Message-----
> From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
> Sent: Thursday, November 29, 2001 12:32 PM
> To: t10 at t10.org
> Subject: Re: CHECK CONDITION for an SRR FC-4 Link Service Reject
>
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Kevin D Butt" <kdbutt at us.ibm.com>
> *
>
>
> I have one response to my query.  It is:
> Hi, Kevin.
>
> Did you ever get an answer to your question?  While I don't recall the
> discussion that lead to that statement in FCP-2, it sounds like the
> target
> follows the link reject with the FCP_RESP IU in a new frame -- your
> second
> alternative.
>
> I'd like to hear whatever else you were told.
>
> Thanks,
>
> Paul
>
> Does anybody do this?
>
> To the HBA vendors:
>
> If we modify our code to do this will the HBA's handle it, or are you
> expecting something different?
>
> Thanks,
>
> Kevin D. Butt
> IBM Tape Products
> SCSI and Fibre Channel Microcode Development
> 6TYA, 9032 S. Rita Rd.
> Tucson, AZ  85744
> Office:  (520)799-5280, Tie-line 321
> Lab: (520)799-2869
> Fax:  (520)799-4062
> Email:  kdbutt at us.ibm.com
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Kevin D Butt" <kdbutt at us.ibm.com>
> *
> I need help understanding the text attached below.  It talks about
> returning a CHECK CONDITION when the target responds to an SRR with an
> FCP
> FC-4 Link Service Reject.  How can a target return a check condition
> when
> it's returning an FC-4 Link Service Reject?  Is it intended to say
that
> a
> deferred check condition is created for response to the next SCSI
> command,
> or does it intend that an FCP_RESP IU be sent instead of the FC-4 Link
> Service Reject?
>
> Any clarification would be appreciated.
>
> - FCP-2r7 Section 8.3
> -
> - Addressing:
> - The S_ID field designates the initiator requesting the information
> retransmission. The D_ID field designates the
> - target that is to receive the request. In the event that the target
> responds to the SRR with an FCP FC-4 Link
> - Service Reject, the target shall return CHECK CONDITION status with
> the
> sense key set to HARDWARE
> - ERROR and an additional sense code of INITIATOR DETECTED ERROR
MESSAGE
> RECEIVED. A target that
> - has agreed during PRLI to support retransmission should not reject
> requests for retransmission of the requested
> - frames unless unusual conditions make the retransmission impossible.
> SRR
> requests for exchanges involving
> - logical units that do not support retransmission on a target that
> supports retransmission for other logical units
> - shall be rejected with an FCP FC-4 Link Service Reject containing a
> reason code of "unable to support
> - command request" and a reason code explanation of "unable to supply
> requested data".
>
> Thanks,
>
> Kevin D. Butt
> IBM Tape Products
> SCSI and Fibre Channel Microcode Development
> 6TY/9032-2, 9000 S. Rita Rd.
> Tucson, AZ  85744
> Phone:  (520)799-5280, Tie-line 321-5280
> Fax:  (520)799-4062
> Email:  kdbutt at us.ibm.com
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org

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