SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI - Response/Status



    
    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
    > >
    > >
    >
    >
    >
    >
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:03 2001
6315 messages in chronological order