camcontrol rescan all fails if there is no bus 0

[Ed Maste]

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