Date: Sat, 26 Aug 2006 08:18:18 -0600 From: Scott Long <scottl@samsco.org> To: Danny Braniss <danny@cs.huji.ac.il> Cc: "Kenneth D. Merry" <ken@freebsd.org>, scsi@freebsd.org Subject: Re: iSCSI/luns/check-condition Message-ID: <44F0582A.9080800@samsco.org> In-Reply-To: <E1GGruJ-0001To-9I@cs1.cs.huji.ac.il> References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <E1GGXyv-0007JJ-RG@cs1.cs.huji.ac.il> <F6E2AEDC-1C45-41A1-9B3A-A05E93F44456@wasabisystems.com> <E1GGgKF-00069y-7G@cs1.cs.huji.ac.il> <DDCEA06D-E09F-4021-8CCD-C9451CF90243@wasabisystems.com> <20060825204525.GA8060@nargothrond.kdm.org> <44EF64CF.2060304@samsco.org> <E1GGruJ-0001To-9I@cs1.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
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..@.@.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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44F0582A.9080800>