From owner-freebsd-scsi@FreeBSD.ORG Mon Aug 21 19:56:34 2006 Return-Path: X-Original-To: freebsd-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 DFEE216A53C for ; Mon, 21 Aug 2006 19:56:34 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 196F443D79 for ; Mon, 21 Aug 2006 19:56:11 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7LJtai1062630 for ; Mon, 21 Aug 2006 19:55:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7LJtZ6u062625 for freebsd-scsi@FreeBSD.org; Mon, 21 Aug 2006 19:55:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Aug 2006 19:55:35 GMT Message-Id: <200608211955.k7LJtZ6u062625@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 21 Aug 2006 19:56:35 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27059 scsi [sym] SCSI subsystem hangs under heavy load on (Server o kern/28508 scsi problems with backup to Tandberg SLR40 strimmer o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceProbeInfo comm o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/93128 scsi [sym] FreeBSD 6.1 BETA 1 has problems with Symbios/LSI o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x (regression) 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/23314 scsi aic driver fails to detect Adaptec 1520B unless PnP is o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [feature request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/96133 scsi [scsi] [patch] add scsi quirk for joyfly 128mb flash u 6 problems total. From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 24 15:05:43 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 8E7A916A4E1 for ; Thu, 24 Aug 2006 15:05:43 +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 1809543D5A for ; Thu, 24 Aug 2006 15:05:43 +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 1GGGm5-000GTB-EB for scsi@freebsd.org; Thu, 24 Aug 2006 18:05:41 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Aug 2006 18:05:41 +0300 From: Danny Braniss Message-ID: Cc: Subject: 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: Thu, 24 Aug 2006 15:05:43 -0000 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 :-] help, danny PS: this is under FreeBSD 6.1 - stable. From owner-freebsd-scsi@FreeBSD.ORG Thu Aug 24 15:15:46 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 7AC2816A4DD for ; Thu, 24 Aug 2006 15:15:46 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F5D343D53 for ; Thu, 24 Aug 2006 15:15:45 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.6/8.13.6) with ESMTP id k7OFFSR9052150; Thu, 24 Aug 2006 09:15:28 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.6/8.13.6/Submit) id k7OFFSGp052149; Thu, 24 Aug 2006 09:15:28 -0600 (MDT) (envelope-from ken) Date: Thu, 24 Aug 2006 09:15:28 -0600 From: "Kenneth D. Merry" To: Danny Braniss Message-ID: <20060824151528.GA52114@nargothrond.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.88.1/1722/Thu Aug 24 04:29:40 2006 on nargothrond.kdm.org X-Virus-Status: Clean 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: Thu, 24 Aug 2006 15:15:46 -0000 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? Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 00:45:44 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 C37EE16A4DA; Fri, 25 Aug 2006 00:45:44 +0000 (UTC) (envelope-from wdallas@adelphia.net) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4625043D45; Fri, 25 Aug 2006 00:45:44 +0000 (GMT) (envelope-from wdallas@adelphia.net) Received: from mrbill5 ([68.64.251.12]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060825004543.UNZY312.mta9.adelphia.net@mrbill5>; Thu, 24 Aug 2006 20:45:43 -0400 From: "William Dallas" To: "'Kenneth D. Merry'" , "'Danny Braniss'" Date: Thu, 24 Aug 2006 20:45:42 -0400 Message-ID: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20060824151528.GA52114@nargothrond.kdm.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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 00:45:44 -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 -----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? Ken -- Kenneth Merry ken@FreeBSD.ORG _______________________________________________ freebsd-scsi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 08:29:16 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 156F616A4DD; Fri, 25 Aug 2006 08:29:16 +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 9915C43D49; Fri, 25 Aug 2006 08:29:15 +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 1GGX3y-0005gm-6p; Fri, 25 Aug 2006 11:29:14 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Kenneth D. Merry" In-reply-to: Your message of Thu, 24 Aug 2006 09:15:28 -0600 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2006 11:29:14 +0300 From: Danny Braniss Message-ID: 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 08:29:16 -0000 > 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? > this function seems to be doing the correct thing, when the target is NetAPP, and some others. 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 From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 09:28:07 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 D268716A4DF; Fri, 25 Aug 2006 09:28:07 +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 4A7A943D4C; Fri, 25 Aug 2006 09:28:07 +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 1GGXyv-0007JJ-RG; Fri, 25 Aug 2006 12:28:05 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "William Dallas" In-reply-to: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> Comments: In-reply-to "William Dallas" message dated "Thu, 24 Aug 2006 20:45:42 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2006 12:28:05 +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 09:28:07 -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 :-( danny > -----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? > > Ken > -- > Kenneth Merry > ken@FreeBSD.ORG > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 16:56:13 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 C2F3116A4DD; Fri, 25 Aug 2006 16:56:13 +0000 (UTC) (envelope-from wrstuden@wasabisystems.com) Received: from mononoke.wasabisystems.com (mononoke.wasabisystems.com [66.173.145.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB08643D6A; Fri, 25 Aug 2006 16:56:09 +0000 (GMT) (envelope-from wrstuden@wasabisystems.com) Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 42321871F7; Fri, 25 Aug 2006 12:56:08 -0400 (EDT) In-Reply-To: References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William Studenmund Date: Fri, 25 Aug 2006 09:56:00 -0700 To: Danny Braniss X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) 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 16:56:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2006, at 2:28 AM, Danny Braniss wrote: >> 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? 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. 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. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE7yulDJT2Egh26K0RApKHAJ9H1IKB2zzBh9ZDF3QeIpTG4HrCeQCcDdlL WQa7cQqEAZkee7T0RYF/RqQ= =XOxS -----END PGP SIGNATURE----- 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 From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 18:25:39 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 C2ED116A4DF; Fri, 25 Aug 2006 18:25:39 +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 5CBBC43D45; Fri, 25 Aug 2006 18:25:39 +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 1GGgN7-0006Gy-Sp; Fri, 25 Aug 2006 21:25:37 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Kenneth D. Merry" In-reply-to: Your message of Thu, 24 Aug 2006 09:15:28 -0600 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2006 21:25:37 +0300 From: Danny Braniss Message-ID: 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 18:25:39 -0000 just one other fishy matter: i've set max_luns to 1, and it's still trying LUN 0 & LUN 1, how come? ... struct ccb_pathinq *cpi = &ccb->cpi; ... cpi->max_lun = 1; danny From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 18:34:54 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 1617C16A4E5; Fri, 25 Aug 2006 18:34:54 +0000 (UTC) (envelope-from wrstuden@wasabisystems.com) Received: from mononoke.wasabisystems.com (mononoke.wasabisystems.com [66.173.145.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CC1143D5E; Fri, 25 Aug 2006 18:34:42 +0000 (GMT) (envelope-from wrstuden@wasabisystems.com) Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 33DAF871F7; Fri, 25 Aug 2006 14:34:41 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <561BF9E9-C140-4C64-B332-7A62AC640B48@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Date: Fri, 25 Aug 2006 11:34:33 -0700 To: Danny Braniss X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) 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:34:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2006, at 11:25 AM, Danny Braniss wrote: > just one other fishy matter: > i've set max_luns to 1, and it's still trying LUN 0 & LUN 1, how come? > ... > struct ccb_pathinq *cpi = &ccb->cpi; > ... > cpi->max_lun = 1; WAG: it's the maximum defined LUN, not the number of LUNs? Try 0? Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE70K+DJT2Egh26K0RAsiRAJ9GEcsGtXO/etFffro1BIX7CQ/XcACdFaH7 R67y48WNhN+02dwTdx95wfE= =Sqo1 -----END PGP SIGNATURE----- From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 18:37:59 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 9A9E716A4DA; Fri, 25 Aug 2006 18:37:59 +0000 (UTC) (envelope-from wrstuden@wasabisystems.com) Received: from mononoke.wasabisystems.com (mononoke.wasabisystems.com [66.173.145.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 957F043D9A; Fri, 25 Aug 2006 18:37:24 +0000 (GMT) (envelope-from wrstuden@wasabisystems.com) Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id F29D187246; Fri, 25 Aug 2006 14:37:22 -0400 (EDT) In-Reply-To: References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William Studenmund Date: Fri, 25 Aug 2006 11:37:15 -0700 To: Danny Braniss X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) 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:37:59 -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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE70NhDJT2Egh26K0RAryAAJ9gJfAXrrjgDQiPZGndteYW2enBlwCgoELv ZPF6+D6mcbS2UY7AZSxjvBM= =DvCU -----END PGP SIGNATURE----- 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 From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 20:45:50 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 2246B16A4DA for ; Fri, 25 Aug 2006 20:45:50 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CCF943D46 for ; Fri, 25 Aug 2006 20:45:49 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.6/8.13.6) with ESMTP id k7PKjPTt009060; Fri, 25 Aug 2006 14:45:25 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.6/8.13.6/Submit) id k7PKjPGZ009059; Fri, 25 Aug 2006 14:45:25 -0600 (MDT) (envelope-from ken) Date: Fri, 25 Aug 2006 14:45:25 -0600 From: "Kenneth D. Merry" To: William Studenmund Message-ID: <20060825204525.GA8060@nargothrond.kdm.org> References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.88.1/1729/Fri Aug 25 11:57:01 2006 on nargothrond.kdm.org X-Virus-Status: Clean 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 20:45:50 -0000 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 -- Kenneth Merry ken@FreeBSD.ORG 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 From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 22:02:17 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 8D47016A4DD; Fri, 25 Aug 2006 22:02:17 +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 D378844201; Fri, 25 Aug 2006 22:02:15 +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 k7PM28gV025007; Fri, 25 Aug 2006 16:02:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44EF735A.8070308@samsco.org> Date: Fri, 25 Aug 2006 16:02:02 -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: William Studenmund References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <20060825204525.GA8060@nargothrond.kdm.org> <44EF64CF.2060304@samsco.org> <71A64AAF-B229-4109-BA2F-E2AC64A11060@wasabisystems.com> In-Reply-To: <71A64AAF-B229-4109-BA2F-E2AC64A11060@wasabisystems.com> 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: "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 22:02:17 -0000 William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Aug 25, 2006, at 1:59 PM, Scott Long wrote: > >> Kenneth D. Merry wrote: >> >>> On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund wrote: >>> 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. > > > While I think there could be a difference between reported levels, if > LUN 0 reports > SCSI-1, then I think it's appropriate to not put the > LUN in the CDB. SCSI-2 mentions that the LUN field should be set to > zero as SCSI-3 may reclaim the bits (which it did). > > I believe that by the time LUN 0 has been probed, the system should > have enough information to figure out if the device is SCSI-1, SCSI-2. > or SCSI-3 (i.e. sam-X, spc-Y, etc.). I think that Scott's suggestion is > good; if LUN 0 is SCSI-1, fill in the LUN in the CBD. If LUN 0 is > > SCSI-1, don't. > > Also, while probing LUN 0, it's probably best to perform a REPORT LUNS > command. If it succeeds, you 1) don't need to blindly probe, and 2) you > know that you shouldn't put the LUN in the CDB (REPORT LUNS appeared > in SPC, which is SCSI-3). > The REPORT_LUNS angle has been discussed many times in the past. The problem is that it's a risky command without the right heuristics. Older SCSI devices are notorious for going down in flames if given a CDB that they don't understand, so we can't universally send a REPORT_LUNS to every target that responds on LUN 0. We've discussed adding some heuristics to look at the rev field and decide from there, but that's only part of the problem. The other part of the problem involves tackling the CAM probe state machine to handle both the current sequential scan as well as a REPORT_LUNS enumeration. That's not an exceptionally hard task, it just takes a bit of work. Scott From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 22:52: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 F168416A6AA; Fri, 25 Aug 2006 22:52:22 +0000 (UTC) (envelope-from wrstuden@wasabisystems.com) Received: from mononoke.wasabisystems.com (mononoke.wasabisystems.com [66.173.145.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD0D441AD; Fri, 25 Aug 2006 21:50:05 +0000 (GMT) (envelope-from wrstuden@wasabisystems.com) Received: from [10.0.0.10] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2819A871E9; Fri, 25 Aug 2006 17:50:02 -0400 (EDT) In-Reply-To: <44EF64CF.2060304@samsco.org> References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <20060825204525.GA8060@nargothrond.kdm.org> <44EF64CF.2060304@samsco.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71A64AAF-B229-4109-BA2F-E2AC64A11060@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Date: Fri, 25 Aug 2006 14:49:52 -0700 To: "Kenneth D. Merry" X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) 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 22:52:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 25, 2006, at 1:59 PM, Scott Long wrote: > Kenneth D. Merry wrote: >> On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund wrote: >> 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. While I think there could be a difference between reported levels, if LUN 0 reports > SCSI-1, then I think it's appropriate to not put the LUN in the CDB. SCSI-2 mentions that the LUN field should be set to zero as SCSI-3 may reclaim the bits (which it did). I believe that by the time LUN 0 has been probed, the system should have enough information to figure out if the device is SCSI-1, SCSI-2. or SCSI-3 (i.e. sam-X, spc-Y, etc.). I think that Scott's suggestion is good; if LUN 0 is SCSI-1, fill in the LUN in the CBD. If LUN 0 is > SCSI-1, don't. Also, while probing LUN 0, it's probably best to perform a REPORT LUNS command. If it succeeds, you 1) don't need to blindly probe, and 2) you know that you shouldn't put the LUN in the CDB (REPORT LUNS appeared in SPC, which is SCSI-3). Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFE73CHDJT2Egh26K0RAm+qAJ4+HXmkWGjDlQ9N+NBRKLVXRmk7AgCfQHZI RLHACxamcGkzSzAIqiRaw8g= =JcoY -----END PGP SIGNATURE----- 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 From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 26 15:15:58 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 44AFB16A56E; Sat, 26 Aug 2006 15:15:58 +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 DE21744575; Sat, 26 Aug 2006 14:18:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k7QEILhR028471; Sat, 26 Aug 2006 08:18:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44F0582A.9080800@samsco.org> Date: Sat, 26 Aug 2006 08:18:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <20060825204525.GA8060@nargothrond.kdm.org> <44EF64CF.2060304@samsco.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org 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 15:15:58 -0000 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 From owner-freebsd-scsi@FreeBSD.ORG Sat Aug 26 19:01:46 2006 Return-Path: X-Original-To: freebsd-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 4072716A4DD for ; Sat, 26 Aug 2006 19:01:46 +0000 (UTC) (envelope-from mjacob@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 101E2447E6 for ; Sat, 26 Aug 2006 19:01:46 +0000 (GMT) (envelope-from mjacob@FreeBSD.org) Received: from freefall.freebsd.org (mjacob@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7QJ1jXx056111 for ; Sat, 26 Aug 2006 19:01:45 GMT (envelope-from mjacob@freefall.freebsd.org) Received: (from mjacob@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7QJ1jXk056110 for freebsd-scsi@freebsd.org; Sat, 26 Aug 2006 19:01:45 GMT (envelope-from mjacob) Date: Sat, 26 Aug 2006 19:01:45 GMT From: Matt Jacob Message-Id: <200608261901.k7QJ1jXk056110@freefall.freebsd.org> To: freebsd-scsi@freebsd.org Subject: new isp test code/24XX 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 19:01:46 -0000 In order to accomodate the 4Gb QLogic card, the isp driver has had to be restructured in a pretty large way. The 24XX cards have the same rough architecture as all the other QLogic cards, but have massively changed inside (16 -> 32 bit registers; IOCBs that have same names and type fields but different layouts). Between this and the desire to make some changes that will make failover and N-port virtualization in target mode easier to handle, loop and fabric evaluation have also been rewritten (which also better accomodates the 2K port login f/w which is now standard even for 23XX cards). This is a big change and needs some serious test time to get right. The changes were so much that rather than impose this even on -current, some settle time in the FreeBSD Perforce sandbox seemed appropriate. If anyone would like to beta test these changes, please let me know. The more feedback now, the more painless the change later. The perforce depot is //depot/client/newisp. -matt