From owner-freebsd-scsi@FreeBSD.ORG Tue Oct 26 15:55:28 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 E064B1065781 for ; Tue, 26 Oct 2010 15:55:28 +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 857438FC1A for ; Tue, 26 Oct 2010 15:55:28 +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 o9QFtPiF011720; Tue, 26 Oct 2010 09:55:25 -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: Date: Tue, 26 Oct 2010 09:55:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Stone X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, 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 15:55:29 -0000 On Oct 25, 2010, at 10:59 AM, Ryan Stone wrote: > If you issue a "camcontrol rescan all" on a system that does not have > scsi bus 0, camcontrol gets a EINVAL from a CAMIOCOMMAND ioctl and > exits after printing an error while trying to do a XPT_DEV_MATCH. > This is because camcontrol passes a bzero'd ccb to the ioctl without > ever setting the path_id, so CAM looks up path 0 and returns EINVAL if > that bus does not exist. >=20 > This is just slightly annoying if there are no CAM devices on the > system. If you had a system with CAM devices, but no bus 0, then > camcontrol rescan all would always fail. I'm not sure if it's > actually possible to skip path 0, though. >=20 > The following patch resolves the issue for me: > 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); >=20 >=20 > (by the way, should I be using CAM_BUS_WILDCARD or CAM_XPT_PATH_ID? > By the name WILDCARD seems more appropriate but I see that camcontrol > uses CAM_XPT_PATH_ID in getdevtree. It appears unfortunate that CAM_XPT_PATH_ID and CAM_BUS_WILDCARD = evaluate to the same value. CAM_XPT_PATH_ID is supposed to be specific = to the pseudo bus that is owned by the XPT module, so I don't know why = it is this way. I'd suggest to use CAM_BUS_WILDCARD here in case = CAM_XPT_PATH_ID changes in the future. 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? Scott