Date: Tue, 26 Oct 2010 09:55:24 -0600 From: Scott Long <scottl@samsco.org> To: Ryan Stone <rysto32@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: camcontrol rescan all fails if there is no bus 0 Message-ID: <E4EB1292-C4F8-4385-8ACD-58BE792988F1@samsco.org> In-Reply-To: <AANLkTiksEn2DP7Y=x=u99qcf28bBEspOWRnsWUfhaOPg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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. > > 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. > > The following patch resolves the issue for me: > 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); > > > (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? Scotthelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E4EB1292-C4F8-4385-8ACD-58BE792988F1>