iSCSI/luns/check-condition

[Scott Long]

Kenneth D. Merry wrote:
> On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund wrote:
> 
>>On Aug 25, 2006, at 11:22 AM, Danny Braniss wrote:
>>
>>
>>>>>>If this is a result of the inquiry on initial probe (most likely),
>>>>>>you
>>>>>>shouldn't get any more than 4 retries.
>>>>>>
>>>>>>What SCSI status byte, sense key, ASC and ASCQ are you returning?
>>>>
>>>whatever the target sent :-), hopefully i'm picking it up correctly.
>>>the code is at the end.
>>>
>>>
>>>>You really need to answer this question. It's always the first thing
>>>>to do when trying to figure out a SCSI issue.
>>>>
>>>>The only non-good status the target will give out of this command is
>>>>Check Condition, Illegal request, Invalid Field in CDB (ASC/Q
>>>>0x24/0x00). It will also give you a sense-key-specific field
>>>>indicating which byte upset the target.
>>>>
>>>>So fire up wireshark and see what's going on.
>>>>
>>>
>>>this is the INQ:
>>>iSCSI (SCSI Command)
>>>    Opcode: SCSI Command (0x01)
>>>    .0.. .... = I: Queued delivery
>>>    Flags: 0xc1
>>>        1... .... = F: Final PDU in sequence
>>>        .1.. .... = R: Data will be read from target
>>>        ..0. .... = W: No data will be written to target
>>>        .... .001 = Attr: Simple (0x01)
>>>    TotalAHSLength: 0x00
>>>    DataSegmentLength: 0x00000000
>>>    LUN: 0001000000000000
>>
>>Ok! You're setting the LUN right.
>>
>>
>>>    InitiatorTaskTag: 0x0000000d
>>>    ExpectedDataTransferLength: 0x00000024
>>>    CmdSN: 0x0000000c
>>>    ExpStatSN: 0x0000000d
>>>    Response in: 48
>>>SCSI CDB
>>>    LUN: 0x0001
>>>    Opcode: Inquiry (0x12)
>>>    CMDT = 0, EVPD = 0
>>>    Allocation Length: 36
>>>    Vendor Unique = 0, NACA = 0, Link = 0
>>>
>>>0000  00 04 38 a0 c6 07 00 30 1b b1 31 91 08 00 45 00   .. 
>>>8....0..1...E.
>>>0010  00 64 a5 ff 40 00 40 06 66 6d 84 41 50 d3 54  
>>>0c   .d.. at .@.fm.AP.T.
>>>0020  05 07 db d6 0c bc 02 55 c5 d1 76 84 38 de 80 18   .......U..v. 
>>>8...
>>>0030  82 18 51 2a 00 00 01 01 08 0a 03 cd d9 01 00  
>>>00   ..Q*............
>>>0040  00 04 01 c1 00 00 00 00 00 00 00 01 00 00 00  
>>>00   ................
>>>0050  00 00 00 00 00 0d 00 00 00 24 00 00 00 0c 00 00   ......... 
>>>$......
>>>0060  00 0d 12 20 00 00 24 00 00 00 00 00 00 00 00 00   ... .. 
>>>$.........
>>
>>                 ^^
>>
>>[I hope that comes out right, my mailer is using a variable-width font]
>>
>>Note the cdb is 12 20 00 00 24 00. The 20 is where something stored  
>>LUN 1, and it is what the target dislikes.
> 
> 
> CAM will set the LUN number when talking to a device that is SCSI-2 or
> older.  It also has to set the LUN number on the initial inquiry when
> talking to a device that is newer than SCSI-2, because it doesn't know what
> SCSI-rev it claims to be.  (Until it gets the initial inquiry back.)
> 
> 
>>>0070  00 00                                             ..
>>>
>>>and this is the response:
>>>iSCSI (SCSI Response)
>>>    Opcode: SCSI Response (0x21)
>>>    Flags: 0x80
>>>        ...0 .... = o: No overflow of read part of bi-directional  
>>>command
>>>        .... 0... = u: No underflow of read part of bi-directional  
>>>command
>>>        .... .0.. = O: No residual overflow occurred
>>>        .... ..0. = U: No residual underflow occurred
>>>    Response: Command completed at target (0x00)
>>>    Status: Check Condition (0x02)
>>>    TotalAHSLength: 0x00
>>>    DataSegmentLength: 0x00000014
>>>    InitiatorTaskTag: 0x0000000d
>>>    StatSN: 0x0000000e
>>>    ExpCmdSN: 0x0000000d
>>>    MaxCmdSN: 0x00000014
>>>    ExpDataSN: 0x00000000
>>>    BidiReadResidualCount: 0x00000000
>>>    ResidualCount: 0x00000000
>>>    Request in: 45
>>>    Time from request: 0.081560000 seconds
>>>    SenseLength: 0x0012
>>>SCSI: SNS Info
>>>    LUN: 0x0001
>>>    Valid: 1
>>>    .111 0000 = SNS Error Type: Current Error (0x70)
>>>    Filemark: 0, EOM: 0, ILI: 0
>>>    .... 0101 = Sense Key: Illegal Request (0x05)
>>>    Sense Info: 0x00000000
>>>    Additional Sense Length: 10
>>>    Command-Specific Information: 00000000
>>>    Additional Sense Code+Qualifier: Invalid Field In Cdb (0x2400)
>>>    Field Replaceable Unit Code: 0x00
>>>    .. = SKSV: True
>>>    Sense Key Specific: C00001
>>
>>Ok. This indicates that the SKSV is valid, the error is in the CDB,  
>>BPV is clear, and the error is in field 1 (byte 1).
>>
>>
>>>0000  00 30 1b b1 31 91 00 04 38 a0 c6 07 08 00 45 00   . 
>>>0..1...8.....E.
>>>0010  00 78 91 60 40 00 2f 06 8b f8 54 0c 05 07 84  
>>>41   .x.`@./...T....A
>>>0020  50 d3 0c bc db d6 76 84 3d 3e 02 55 c6 01 80 18    
>>>P.....v.=>.U....
>>>0030  ff ff cb 19 00 00 01 01 08 0a 00 00 00 05 03  
>>>cd   ................
>>>0040  d9 01 21 80 00 02 00 00 00 14 00 00 00 00 00  
>>>00   ..!.............
>>>0050  00 00 00 00 00 0d 00 00 00 00 00 00 00 0e 00  
>>>00   ................
>>>0060  00 0d 00 00 00 14 00 00 00 00 00 00 00 00 00  
>>>00   ................
>>>0070  00 00 00 12 f0 00 05 00 00 00 00 0a 00 00 00  
>>>00   ................
>>>0080  24 00 00 c0 00 01                                 $.....
>>>
>>>
>>>>Nothing happens to be trying to put the LUN in bits 5 through 7 of
>>>>byte 1 perchance? They have been reserved since SPC2 or earlier.
>>>>Trying to put the LUN there will cause the issue you're seeing.
>>>>
>>>
>>>I don't deal with the ccb, it's the cam.
>>
>>Hmm... I'm not sure how to fix this then. The problem is that the  
>>specs indicate that this is no longer valid. They do not indicate  
>>obsolete (the "obsolete" term exists for that), they are invalid  
>>("reserved in SPC2). There are test suites (which have been run  
>>against us) that make sure the use of any "reserved" bit causes an  
>>error.
> 
> 
> See above...CAM sets the LUN number when it does the initial probe of a
> LUN, and when the LUN reports it is SCSI-2 or below.
> 
> The problem with rejecting the LUN number on the inquiry is that the
> initiator is issuing the inquiry to find out what SCSI rev the target is in
> the first place.  It has to do so in a way that will work on old and new
> targets.
> 
> Things work okay on LUN 0, because the LUN field is set to 0.
> 
> My suggestion would be to allow setting of the LUN number on the inquiry
> command only.  That way the initiator can figure out what SCSI rev you are
> and do things accordingly.
> 
> Ken

Are there cases where a target has multiple LUNs that will each report a 
different SCSI rev?  If not, then CAM should look at the rev of LUN 0 of 
the target when deciding how to form an INQ of LUNs >0.

Scott