From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 18:22: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 D23DE16A4DA; Fri, 25 Aug 2006 18:22: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 DACBA43D46; Fri, 25 Aug 2006 18:22: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 1GGgKF-00069y-7G; Fri, 25 Aug 2006 21:22:39 +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 09:56:00 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2006 21:22:38 +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: Fri, 25 Aug 2006 18:22:41 -0000 > >> Danny, > >> > >> LUN 1 should not be returning a chk condition in response to an > >> INQUIRY > >> command with the page code and EVPD both 0 in the cdb. The device > >> server should return the inquiry response data with the peripheral > >> device qualifier set to 001b or 011b (1 or 3) per the scsi specs. > >> > >> Bill > >> > > hi Bill, > > that's 'wishfull thinking' :-), I can only fix the initiator, the > > target > > I have to live with :-( > > Actually, I believe the target is behaving correctly. See below. > > >> -----Original Message----- > >> From: owner-freebsd-scsi@freebsd.org > >> [mailto:owner-freebsd-scsi@freebsd.org] On Behalf Of Kenneth D. Merry > >> Sent: Thursday, August 24, 2006 11:15 AM > >> To: Danny Braniss > >> Cc: scsi@freebsd.org > >> Subject: Re: iSCSI/luns/check-condition > >> > >> On Thu, Aug 24, 2006 at 18:05:41 +0300, Danny Braniss wrote: > >>> hi, > >>> this target (Wasabi) is returning Check Condition for > >>> a INQ. LUN 1, (which probably is ok, since it does not exist), I > >> return > >>> ccb_h->status = CAM_SCSI_STATUS_ERROR; > >>> but it seems that the CAM is ignoring it, since it will try > >>> again, and > >>> again, etc. [or i'm doing something wrong :-] > >> > >> 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 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 ... ..$......... 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 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. > Take care, > > Bill the code: static void getSenseData(u_int status, union ccb *ccb, pduq_t *pq) { pdu_t *pp = &pq->pdu; struct ccb_scsiio *scsi = (struct ccb_scsiio *)ccb; struct scsi_sense_data *sense = &scsi->sense_data; struct ccb_hdr *ccb_h = &ccb->ccb_h; caddr_t bp = mtod(pq->mp, caddr_t); struct mbuf *m = pq->mp; scsi_rsp_t *cmd = &pp->ipdu.scsi_rsp; int sense_len, mustfree = 0; sense_len = scsi_2btoul(bp); /* | according to the specs, the sense data cannot | be larger than 252 ... */ if(sense_len > m->m_len) { bp = malloc(sense_len, M_ISCSI, M_WAITOK); debug(3, "calling i_mbufcopy(len=%d)", sense_len); i_mbufcopy(pq->mp, bp, sense_len); mustfree++; } scsi->scsi_status = status; bcopy(bp+2, sense, min(sense_len, scsi->sense_len)); scsi->sense_resid = 0; if(cmd->flag & (BIT(1)|BIT(2))) scsi->sense_resid = ntohl(pp->ipdu.scsi_rsp.rcnt); debug(3, "sense_len=%d rcnt=%d sense_resid=%d dsl=%d error_code=%x flags=%x", sense_len, ntohl(pp->ipdu.scsi_rsp.rcnt), scsi->sense_resid, pp->ds_len, sense->error_code, sense->flags); ccb_h->status |= CAM_AUTOSNS_VALID; if(mustfree) free(bp, M_ISCSI); } thanks, danny