From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 16:41:15 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 60473106566B for ; Tue, 26 Oct 2010 16:41:15 +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 F0EA48FC1B for ; Tue, 26 Oct 2010 16:41:14 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o9QGfBCJ011987; Tue, 26 Oct 2010 10:41:11 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20101026160457.GA61133@sandvine.com> Date: Tue, 26 Oct 2010 10:41:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9EC3B874-B089-4ED4-9A12-FA7A0E170A7B@samsco.org> References: <20101026160457.GA61133@sandvine.com> To: Ed Maste X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, MIME_QP_LONG_LINE, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org 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:41:15 -0000 On Oct 26, 2010, at 10:04 AM, Ed Maste wrote: > On Tue, Oct 26, 2010 at 09:55:24AM -0600, Scott Long wrote: >=20 >> On Oct 25, 2010, at 10:59 AM, Ryan Stone wrote: >>=20 >>> ... >>> Index: camcontrol.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- 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 =3D XPT_DEV_MATCH; >>> + matchccb.ccb_h.path_id =3D CAM_BUS_WILDCARD; >>> bufsize =3D sizeof(struct dev_match_result) * 20; >>> matchccb.cdm.match_buf_len =3D bufsize; >>> matchccb.cdm.matches=3D(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? >=20 > That's this comment block I presume: >=20 > /* > * 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. > */ >=20 > 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? >=20 > -Ed Ok, I guess I need to see if CAM_XPT_PATH_ID can get returned from the = devmatch. What happens with this patch if you run it with no real buses = registered (i.e. cam module present, but no SIMs present)? Scott