From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 21:00:15 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 E4D3E16A4DE; Fri, 25 Aug 2006 21:00:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C30F43D53; Fri, 25 Aug 2006 21:00:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k7PL04c2024806; Fri, 25 Aug 2006 15:00:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44EF64CF.2060304@samsco.org> Date: Fri, 25 Aug 2006 14:59:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kenneth D. Merry" References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <20060825204525.GA8060@nargothrond.kdm.org> In-Reply-To: <20060825204525.GA8060@nargothrond.kdm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.5 required=3.8 tests=SPF_SOFTFAIL autolearn=no version=3.1.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: 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: Fri, 25 Aug 2006 21:00:15 -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