Re: iSCSI - Response/Status

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

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" <ESQuicksall@hotmail.com> on 10-08-2001 18:00:31

Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
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" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
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" <ESQuicksall@hotmail.com> on 09-08-2001 22:16:50
>
> Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   <ips@ece.cmu.edu>
> 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" <Julian_Satran@il.ibm.com>
> To: <ips@ece.cmu.edu>
> 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
> >
> >
>
>
>
>