Response IU

Thu May 16 07:18:04 PDT 2002

* From the T10 Reflector (t10 at t10.org), posted by:
* "John Tyndall" <jtyndall at Crossroads.com>
*
Actually in FCP-2 (section 9.4.6), there is language declaring that if the FCP_RSP_LEN_VALID bit is set then the SCSI_STATUS field is unreliable and SHALL be ignored. I would think that if SCSI status must be ignored then then so should sense data. This has caused some confusion. I think the intent is to limit use of the response code to transport problems and task management responses only. 

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

-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com] 
Sent: Thursday, May 16, 2002 8:28 AM
To: t10
Subject: RE: Response IU

* From the T10 Reflector (t10 at t10.org), posted by:
* "George Penokie" <gop at us.ibm.com>
*

Bill,
One man's nonsensical case may be anothers neccessary.

This case is not prevented in FCP-2, SPI-3, SPI-4, and who knows about the other protocols. So why is it an issue in SAS?

I still contend that it would be perfectly resonable to have both bits active. The RSPVALID field is limited 4 bytes in SPI and 8 bytes in FCP-2 so generally does not contain much information. If a case comes up where the target needs to report a protocoal failure and needs to report more information then sense data could also be generated.

In addition there is nothing that states that a protocol error and a command error can not be related. If they are then it would be resonable to report both in one shot. In that case I would see the protocol error informing the protocol level of the error and the sense data informating the application of the command error.

Bye for now,
George Penokie

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

                      "Bill Galloway"                                                                                                  
                      <BillG at breatech.c        To:       George Penokie/Rochester/IBM at IBMUS, <t10 at t10.org>                             
                      om>                      cc:                                                                                     
                      Sent by:                 Subject:  RE: Response IU                                                               
                      owner-t10 at t10.org                                                                                                

                      05/15/02 06:48 PM                                                                                                
                      Please respond to                                                                                                
                      BillG                                                                                                            

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill Galloway" <BillG at breatech.com>
*
The reason to make it illegal is not to enforce some silly check but to make hardware simpler.  There is no reason to make hardware handle the case for both bits set if it never makes sense for them to both be set.

Throwing out nonsensical cases makes the hardware simpler.

Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at breatech.com

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George Penokie
Sent: Wednesday, May 15, 2002 5:38 PM
To: t10
Subject: Re: Response IU

* From the T10 Reflector (t10 at t10.org), posted by:
* "George Penokie" <gop at us.ibm.com>
*

Bill,
I see no reason to add in another check when it is not needed. There is nothing wrong with having both the RSPVALID and SNSVALID bits set and having corresponding information available in their data fields. So what if we can't think of a reason why both would have information in them in todays implementations.

Whenever we state something is illegal it just adds in another condition that needs to be tested. I say leave it up to the implementer to determine.

Bye for now,
George Penokie

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

                      "Bill Galloway"

                      <BillG at breatech.c        To:       "'T10
Reflector'" <t10 at t10.org>
                      om>                      cc:

                      Sent by:                 Subject:  Response IU

                      owner-t10 at t10.org

                      05/14/02 09:26 PM

                      Please respond to

                      BillG

* From the T10 Reflector (t10 at t10.org), posted by:
* "Bill Galloway" <BillG at breatech.com>
*
This is a question about FCP, SPI-4, SRP, and SAS Response IU format.

Is it ever possible for both the RSP_LEN and SNS_LEN bits to be set.

I do not think it is because if RSP_LEN is set then the STATUS field is ignored. If the STATUS is ignored then is it even possible to interpret sense data? I do not know about the response values associated with FCP_DATA (in FCP) but all other responses either prevent the command from being accepted by the target or are task management responses. None of these cases have sense data.

The second question is for what STATUS codes is auto-sense data allowed?

CHECK CONDITION = yes
GOOD = ????
All Others = disallowed.

What is the answer for GOOD and does anyone know of a reason to send sense data for the other status codes? Is it REQUIRED for CHECK CONDITION?

Bill Galloway
BREA Technologies, Inc.
P: (281) 530-3063
F: (281) 988-0358
BillG at breatech.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