Date: Tue, 26 Sep 2006 19:46:53 -0700 (PDT) From: mjacob@freebsd.org To: Ade Lovett <ade@freebsd.org> Cc: scsi@freebsd.org Subject: Re: hysteresis for CAM_RESRC_UNAVAIL Message-ID: <20060926193731.G5448@ns1.feral.com> In-Reply-To: <92A8EEB3-28FD-45A2-8099-AD0942820C4B@FreeBSD.org> References: <20060926085839.Q98053@ns1.feral.com> <4519A603.8080108@samsco.org> <92A8EEB3-28FD-45A2-8099-AD0942820C4B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 26, 2006, at 15:13 , Scott Long wrote: >> I think the intent here was to have some sort of an asynchronous "resource >> is now available" and "I'm no longer busy" mechanism, maybe via an AC_ >> message. However, a think that the timeout that you're proposing is much >> better than the vacuum that is there now. > > Definitely the goal should be towards an async notification mechanism. The trouble here is that there is nothing in the SCSI spec to tell you *when* a device that reported a BUSY will no longer be busy. In the case of the return for CAM_RESRC_UNAVAIL that came out of the mpt driver it turns out that this is info out of the IOC with no info as to when resources *will* become available again either. In both of these cases, an async notification mechanism would be timeout driven at the sim level. > In the meantime, rather than hard-coding half a second, could we have the > timeout be a sysctl for easier experimentation as to what an "appropriate" > value would be? (defaulting to 500ms) Gives a few extra options to tinker > with things if a suitably degenerate case can be found with which to exercise > this code, rather than having to recompile the kernel. Providing > progressively longer delays on repeated calls to cam_periph_error() seems to > be somewhat non-trivial since it's going to require maintaining extra state. Umm- but then this has to be documented, and so on and so forth. I mean, you might have to tune such a value, but it strikes me that under the current circumstances that because nobody has *really* complained about this situation for > 5 years that nobody will really *need* to tune it, so maybe we need not do it at all :-). Maybe this should be pushed off to each SIM driver then. That is, let each SIM (or otherwise setter of BUSY or CAM_RESRC_UNAVAIL status) just freeze the device queue or simq as appropriate and then unfreeze it later. -matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060926193731.G5448>