hysteresis for CAM_RESRC_UNAVAIL

[mjacob at freebsd.org]

> 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