iSCSI/luns/check-condition

Scott Long scottl at samsco.org
Sat Aug 26 15:15:58 UTC 2006


Danny Braniss wrote:

>>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
>>
> 
> sorry to barge in :-)
> but my initial problem was that the driver went into a loop.
> 	0- cam starts lun discovery
> 	1- cam sends inq
> 	2- target replies 'condition check'
> 	3- cam ignores,
> 	4- back to 1

This is only going to happen if the SIM is returning CAM_REQ_CMP.
You should be returning CAM_REQ_CMP_ERROR.  An ASC of 0x24 will set
SS_FATAL, which will cause probedone() to break out of the probe
sequence.

> 
> and i want to stop this.
> 
> also, I understand the lun discovery problematic, but what if:
> 	when the CAM does a XPT_PATH_INQ,
> 	setting cpi->max_lun to CAM_DO_LUN_DISCOVERY value
> triggers a different discovery algorithm?

This would in effect allow the SIM to provide hints on how to scan
the devices that it owns, which is a good idea.

> 
> danny
> PS: getting close to a new release of iscsi_initiator
> 
> 

Keep up the good work!

Scott



More information about the freebsd-scsi mailing list