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