camcontrol rescan all fails if there is no bus 0

Scott Long scottl at samsco.org
Tue Oct 26 15:55:29 UTC 2010


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?

Scott




More information about the freebsd-scsi mailing list