Subject: RE: iSCSI - Response/Status

From: "Elliott, Robert" <[email-masked]>
Date: Fri, 10 Aug 2001 05:03:57 -0500

I would call out those additional sense codes by name rather than number
(perhaps both).  The sense key(s) to be used also need to be listed.

Status=CHECK CONDITION
Sense Key=
additional sense code (ASC+ASCQ)=

--
[email-masked]
Compaq Computer Server Storage

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 6:34 PM
To: [email-masked]
Subject: iSCSI - Response/Status

According to the discusions on the list 2.4.2 & 2.4.3 have been fixed to
read:

1.1.1     Status

   The Status field is used to report the SCSI status of the command (as
   specified in [SAM2]) and is valid only if the Response Code is Command
   Completed at target.

   If a SCSI device error is detected while data from the initiator is
   still expected (the command PDU did not contain all the data and the
   target has not received a Data PDU with the final bit Set) the target
   MUST wait until it receives the a Data PDU with the F bit set, in the
   last expected sequence, before sending the Response PDU.

1.1.2     Response

   This field contains iSCSI service response.

   Valid iSCSI service response codes are:

      0x00 - Command Completed at Target
      0x01 - Target Failure
      0x02 - Delivery Subsystem Failure
      0x80-0xff - Reserved for Vendor-Unique Responses

   The Response is used to report a Service Response. The exact mapping of
   the iSCSI response codes to SAM service response symbols is outside the
   scope of this document.

   Certain iSCSI conditions result in the command being terminated at the
   target (response Command Completed at Target) with a SCSI Check
   Condition Status as outlined in the next table:

   +------------------------------+---------------------------+
   | Reason                       | with SCSI CHECK CONDITION |
   +------------------------------+---------------------------+
   | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | Not enough unsolicited       | ASC = 0x4B ASCQ = 0x00    |
   +------------------------------+---------------------------+
   | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
   +------------------------------+---------------------------+

   N.B. Unsolicited data rejected condition is reported used by the target
   only if it does not support output (write) operations in which the total
   data length is higher than FirstBurstSize but the initiator sent less
   than first burst size and out-of-order R2Ts can't be used.

   Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 11 Aug 2001 01:33:55 +0300

We left them both as they might end-up not being mutually exclusive
sometime in the future.
On the surface it looks like the FCP designers went through the same line
of argument.

Regards,
Julo

"Eddy Quicksall" <[email-masked]> on 10-08-2001 18:00:31

Please respond to "Eddy Quicksall" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <[email-masked]>
Subject:  Re: iSCSI - Response/Status

Sorry, I get it now ... I was mixing the old and new in my thinking.

But, I'm still wondering why the S bit was removed and the fields were put
into two places because they still seem to be mutually exclusive. I really
don't have a problem but I thought someone had a good idea since the S bit
clearly showed they are mutually exclusive.

Also, it looks like the old S bit has been changed to a fixed zero instead
of a reserved bit. Could it be that in this case "0" means "reserved"?

Eddy

----- Original Message -----
From: "Julian Satran" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 10, 2001 3:07 AM
Subject: Re: iSCSI - Response/Status

>
> Eddy,
>
> The iSCSI condition is listed under reason.
> The Response field is 00 (else the status is not valid) as stated in the
> first paragraph..
>
> Julo
>
> "Eddy Quicksall" <[email-masked]> on 09-08-2001 22:16:50
>
> Please respond to "Eddy Quicksall" <[email-masked]>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <[email-masked]>
> Subject:  Re: iSCSI - Response/Status
>
>
>
> Can you list, in the table, which "iSCSI conditions" result in the Check
> Condition?
>
> Also, would it be useful to make it clear that the Status and Response
> fields would both be set in this case?
>
> Eddy
> ----- Original Message -----
> From: "Julian Satran" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, August 09, 2001 1:33 PM

---

From: Rick Ellis <[email-masked]>
Date: Fri, 10 Aug 2001 09:32:37 -0700

>last expected sequence, before sending the Response PDU.

Is there any provision for timeout?

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 12 Aug 2001 01:31:47 +0300

Thanks Elliot - I am not sure that we have it closed we may have to
rearrange things.
There is nothing to convey the fact that this was an error originated in
iSCSI at the target and the detailed nature of the error (we had this in
the iSCSI response, now we might have to add this information to sense.

Julo

"Elliott, Robert" <[email-masked]>@ece.cmu.edu on 10-08-2001
13:03:57

Please respond to "Elliott, Robert" <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: iSCSI - Response/Status

Status=CHECK CONDITION
Sense Key=

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 09, 2001 6:34 PM
To: [email-masked]
Subject: iSCSI - Response/Status

1.1.1     Status

1.1.2     Response

   Julo