From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 26 06:44:41 2006 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BA5E16A4DD; Sat, 26 Aug 2006 06:44:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2B5943D53; Sat, 26 Aug 2006 06:44:40 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GGruJ-0001To-9I; Sat, 26 Aug 2006 09:44:39 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <44EF64CF.2060304@samsco.org> References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <20060825204525.GA8060@nargothrond.kdm.org> <44EF64CF.2060304@samsco.org> Comments: In-reply-to Scott Long message dated "Fri, 25 Aug 2006 14:59:59 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Aug 2006 09:44:39 +0300 From: Danny Braniss Message-ID: Cc: "Kenneth D. Merry" , scsi@freebsd.org Subject: Re: iSCSI/luns/check-condition X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 06:44:41 -0000 > 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 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