Re: iSCSI: underrun with a check condition

["Julian Satran" <Julian_Satran@il.ibm.com>]

Santosh,

I don't know the scenario you had in
mind.
The SCSI LLP gets status (Busy, ACA
active, etc.) that tells explicitly that the command did not execute.

Julo

Santosh Rao <santoshr@cup.hp.com>
Sent by: owner-ips@ece.cmu.edu

17/02/03 12:12

To	satran@haifasphere.co.il (Julian Satran)
cc	santoshr@cup.hp.com ('Santosh Rao'), eddyq@ivivity.com ('Eddy Quicksall'), ips@ece.cmu.edu ("'\"Ips@Ece.Cmu.Edu\"'")
Subject	Re: iSCSI: underrun with a check condition

Julian,

The initiator SCSI LLP would not know if the device server processed 
the command successfully or not, except for the u/o/resid information.
If the
device server did not process the command and returned a RECOVERED ERROR
check
condition on it, the host may process the completion as if the command
had
completed successfully, since the resid field will be 0 and the u/o bits
not
set.

Such behaviour can result in a corrupt read due to the read being completed
with success, but no data having been read into the read data buffer. 

SAM-2 Section 5.3.2 is only discussing SCSI status precedence. It does
not
explain the resid reporting precedence compared to SCSI status. 

Regards,
Santosh



> 
> Santosh,
> 
> For any check condition in which the target did process the command
this
> is the expected behavior.
> The example Eddy gave involves a target that due to ACA or BUSY does
not
> initiate processing the command.
> In this case the target provider does not HAVE TO set the U/O bits
(and
> the associated values).
> The relevant piece of information appears in SAM2 5.3.2 that indicates
> that status precedence.
> Obviously a target MAY set the U/O bits although  I doubt that
an
> initiator will look them up.
> 
> Regards,
> Julo
> 
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf
Of
> Santosh Rao
> Sent: 16 February, 2003 23:28
> To: Eddy Quicksall
> Cc: "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)"
> Subject: Re: iSCSI: underrun with a check condition
> 
> 
> Eddy,
> 
> Yes, anytime the amount of data transferred does not match the data
> transfer length specified, the target must set the U bit or O bit,
> depending on whether an underflow or overflow occurred.
> 
> A recovered error check condition may be returned as the response
to a
> scsi command which was processed to completion. The recovered error
> indicates that a previous command completed successfully with some
> recovery action by the device server and the sense data provides
> additional details on that previous command.
> 
> The current command on which a recovered error check condition was
> returned may have been processed to completion, or experienced some
> underflow or overflow. This information must be conveyed by the target
> in the iscsi scsi response pdu using the appropriate fields to describe
> the underflow or overflow.
> 
> Thanks,
> Santosh
> 
> 
> > Should the target set the U bit when it gives a check condition
to a 
> > data-in command?
> >  
> >  
> > Eddy
> 
> 


-- 
**************************
Santosh Rao
HP-UX SCSI Team,
Hewlett Packard, Cupertino
**************************