Subject: Re: iSCSI - Response/Status

From: "Julian Satran" <[email-masked]>
Date: Fri, 10 Aug 2001 10:07:50 +0300

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
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: "Eddy Quicksall" <[email-masked]>
Date: Fri, 10 Aug 2001 11:00:31 -0400

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