From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 16:04:58 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9134F10656A3 for ; Tue, 26 Oct 2010 16:04:58 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 52D4D8FC1B for ; Tue, 26 Oct 2010 16:04:58 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Tue, 26 Oct 2010 12:04:57 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 610E533C00; Tue, 26 Oct 2010 12:04:57 -0400 (EDT) Date: Tue, 26 Oct 2010 12:04:57 -0400 From: Ed Maste To: Scott Long Message-ID: <20101026160457.GA61133@sandvine.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol rescan all fails if there is no bus 0 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: Tue, 26 Oct 2010 16:04:58 -0000 On Tue, Oct 26, 2010 at 09:55:24AM -0600, Scott Long wrote: > On Oct 25, 2010, at 10:59 AM, Ryan Stone wrote: > > > ... > > Index: camcontrol.c > > =================================================================== > > --- camcontrol.c (revision 214271) > > +++ camcontrol.c (working copy) > > @@ -1519,6 +1519,7 @@ rescan_or_reset_bus(int bus, int rescan) > > bzero(&(&matchccb.ccb_h)[1], > > sizeof(struct ccb_dev_match) - sizeof(struct ccb_hdr)); > > matchccb.ccb_h.func_code = XPT_DEV_MATCH; > > + matchccb.ccb_h.path_id = CAM_BUS_WILDCARD; > > bufsize = sizeof(struct dev_match_result) * 20; > > matchccb.cdm.match_buf_len = bufsize; > > matchccb.cdm.matches=(struct dev_match_result *)malloc(bufsize); > > ... > ... > That being said, there's a comment block right above the code that you changed that suggests that the XPT pseudo-bus handler won't behave correctly if it gets a rescan or reset command, hinting that that's why the enumeration starts specifically a '0' instead of 'CAM_BUS_WILDCARD'. Did you see any evidence of this in your testing? That's this comment block I presume: /* * The right way to handle this is to modify the xpt so that it can * handle a wildcarded bus in a rescan or reset CCB. At the moment * that isn't implemented, so instead we enumerate the busses and * send the rescan or reset to those busses in the case where the * given bus is -1 (wildcard). We don't send a rescan or reset * to the xpt bus; sending a rescan to the xpt bus is effectively a * no-op, sending a rescan to the xpt bus would result in a status of * CAM_REQ_INVALID. */ I think it's still true; Ryan's change uses CAM_BUS_WILDCARD for the XPT_DEV_MATCH ioctl in order to enumerate the busses, and the path_id that gets used for the actual rescan or reset should be that returned from the match should it not? -Ed