iSCSI/luns/check-condition

Sat Aug 26 06:44:41 UTC 2006

> 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

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?

danny
PS: getting close to a new release of iscsi_initiator