Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Oct 2010 12:04:57 -0400
From:      Ed Maste <emaste@freebsd.org>
To:        Scott Long <scottl@samsco.org>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: camcontrol rescan all fails if there is no bus 0
Message-ID:  <20101026160457.GA61133@sandvine.com>
In-Reply-To: <E4EB1292-C4F8-4385-8ACD-58BE792988F1@samsco.org>
References:  <AANLkTiksEn2DP7Y=x=u99qcf28bBEspOWRnsWUfhaOPg@mail.gmail.com> <E4EB1292-C4F8-4385-8ACD-58BE792988F1@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101026160457.GA61133>