iSCSI/luns/check-condition

Fri Aug 25 18:37:59 UTC 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

Take care,

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE70NhDJT2Egh26K0RAryAAJ9gJfAXrrjgDQiPZGndteYW2enBlwCgoELv
ZPF6+D6mcbS2UY7AZSxjvBM=
=DvCU
-----END PGP SIGNATURE-----