Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h1HBm7407084 for ips-outgoing; Mon, 17 Feb 2003 06:48:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h1HBm1W07080 for ; Mon, 17 Feb 2003 06:48:01 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1HBlaWT066590; Mon, 17 Feb 2003 12:47:41 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1HBlakU261856; Mon, 17 Feb 2003 12:47:36 +0100 In-Reply-To: <200302171012.CAA14380@hpcuhe.cup.hp.com> To: Santosh Rao Cc: eddyq@ivivity.com ('Eddy Quicksall'), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, santoshr@cup.hp.com ('Santosh Rao'), satran@haifasphere.co.il (Julian Satran) Subject: Re: iSCSI: underrun with a check condition MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: "Julian Satran" Message-ID: Date: Mon, 17 Feb 2003 13:47:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/02/2003 13:47:35, Serialize complete at 17/02/2003 13:47:35 Content-Type: multipart/alternative; boundary="=_alternative 004023CDC2256CD0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004023CDC2256CD0_= Content-Type: text/plain; charset="US-ASCII" 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 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 ************************** --=_alternative 004023CDC2256CD0_= Content-Type: text/html; charset="US-ASCII"
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
**************************
--=_alternative 004023CDC2256CD0_=--