From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 20:15:23 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 0E18716A4DF; Fri, 25 Aug 2006 20:15:23 +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 6DC2643D49; Fri, 25 Aug 2006 20:15:22 +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 1GGi5I-0009BG-IF; Fri, 25 Aug 2006 23:15:20 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: William Studenmund In-reply-to: References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> Comments: In-reply-to William Studenmund message dated "Fri, 25 Aug 2006 11:37:15 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2006 23:15:20 +0300 From: Danny Braniss Message-ID: Cc: "'Kenneth D. Merry'" , Jonathan Gilpin , 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 20:15:23 -0000 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. > > > 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. > > Take care, > > Bill ok, setting max_luns to 'the highest lun', 0, stopped the INQs for LUN1, and so it's working! this is a kludge, IMHO, but i guess Jonathan will be happy. Aug 25 23:07:55 shuttle-3 kernel: da2 at iscsi0 bus 0 target 0 lun 0 Aug 25 23:07:55 shuttle-3 kernel: da2: Fixed Direct Access SCSI-5 device Aug 25 23:07:55 shuttle-3 kernel: da2: 210000MB (430080000 512 byte sectors: 255H 63S/T 26771C) danny