no outstanding XFER_RDY when DATA received

[Elliott, Robert (Server Storage)]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
For other transport layer frame sequencing errors like this, the
response from a target (see 9.2.5.1) is generally a CHECK CONDITION
(with additional sense codes of INVALID TARGET PORT TRANSFER TAG
RECEIVED, TOO MUCH WRITE DATA, INFORMATION UNIT TOO SHORT, or DATA
OFFSET ERROR).  The response from an initiator (see 9.2.5.2) to similar
problems is to abort the command.

My initial take was that it fell under the CHECK CONDITION/TOO MUCH
WRITE DATA category, but was convinced that's not the best result.

--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott




> -----Original Message-----
> From: Jim.Coomes at seagate.com [mailto:Jim.Coomes at seagate.com] 
> Sent: Friday, May 02, 2003 1:29 PM
> To: Evans, Mark
> Cc: t10 at t10.org
> Subject: SAS: no outstanding XFER_RDY when DATA received
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Jim.Coomes at seagate.com
> *
> Mark,
> 
> There is an easier fix, discard the frame. The behavior below 
> adds complexity to cover a broken initiator. It just provides 
> a tool to debug the problem. A trace analyzer will do the same.
> 
> Jim
> ----- Forwarded by Jim Coomes/Seagate on 05/02/2003 01:22 PM -----
>                                                               
>                                                               
>            
>                       "Evans, Mark"                           
>                                                               
>            
>                       <Mark_Evans at maxto        To:       
> t10 at t10.org                                                   
>                 
>                       r.com>                   cc:            
>                                                               
>            
>                       Sent by:                 Subject:  SAS: 
>  no outstanding XFER_RDY when DATA received                   
>            
>                       owner-t10 at t10.org                       
>                                                               
>            
>                       No Phone Info                           
>                                                               
>            
>                       Available                               
>                                                               
>            
>                                                               
>                                                               
>            
>                       05/02/2003 11:42                        
>                                                               
>            
>                       AM                                      
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
> 
> 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Evans, Mark" <Mark_Evans at maxtor.com>
> *
> Hello,
> 
> We've identified an error condition that is not described in 
> SASr3g:  what does a target port do if it receives a DATA 
> frame, the DATA frame has the tag of a data out command that 
> has been received, but neither first burst is enabled nor is 
> there an outstanding XFER_RDY for the tag.  The following are 
> recommended modifications to the SAS draft (and SPC-3 for a 
> new ASC/ASCQ) to resolve this issue.
> 
> 1) I propose a new ASC/ASCQ, INVALID FRAME RECEIVED.  I 
> recommend that this be one of the "4B" ASCs ("06" is the next 
> available ASCQ in this group in SPC-3r12).
> 
> 2) Add a new paragraph below the seventh paragraph in 9.2.5.1 
> SSP target port error handling ("If an SSP target port 
> receives a DATA frame with an unknown tag, it shall discard 
> the frame (see 9.2.6.3.2)").  This paragraph should be 
> something like, "If an SSP target port receives a DATA frame, 
> the frame is not first burst data, and there is no 
> outstanding XFER_RDY for the tag, the target port shall 
> terminate the command with a CHECK CONDITION status with a 
> sense key of ABORTED COMMAND and an additional sense code of 
> INVALID FRAME RECEIVED (see 10.2.3)."
> 
> 3) Add a new item (b) in the second bulleted list in 
> 9.2.6.3.3.5.1 [ST_TTS4:Receive_Data_Out] State description 
> something like, "check the tag value in the DATA frame. If an 
> XFER_RDY frame has not been sent for the data, and this is 
> not first burst data, then this state shall send a Data-Out 
> Received (Delivery Result = DELIVERY FAILURE - INVALID FRAME
> RECEIVED) transport protocol service confirmation to the SCSI 
> application layer.  This confirmation shall include the tag. 
> This state machine shall terminate after sending the confirmation;"
> 
> 4) In Table 124 - Delivery Result to additional sense code 
> mapping in 10.2.3 Device server error handling add a row for 
> DELIVERY FAILURE - INVALID FRAME RECEIVED.
> 
> Please feel free to call or send an email to me with any 
> questions or comments that you may have about this.
> 
> Regards,
> 
> Mark Evans
> Maxtor Corporation
> 408-894-5310
> *
> * 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