hysteresis for CAM_RESRC_UNAVAIL

[Ade Lovett]

On Sep 26, 2006, at 19:46 , mjacob at freebsd.org wrote:
> 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.

Well, I guess that puts a fundamental damper on async notifications  
then ;)

> 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 :-).

I was thinking more in terms of initial experimentation.  Consider it  
a "hidden" sysctl.  One with a likely very short lifespan.  Rather  
than hardcoding a number, add in the minimal extra code to allow it  
to be tunable.  We have a relatively large number of tunables that  
simply aren't tuned in a "standard" setup.  I'm thinking of it more  
in terms of allowing for a little bit of flexibility - I have this  
(irrational?) hatred of hard-coded numbers.

> 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.

Oof.  At the very least, we'd be looking at a reasonably large chunk  
of duplicated code in this instance, no?

The concept of backing off a little on a BUSY/UNAVAIL definitely has  
merit, as opposed to the "bugger it, we'll just keep trying harder  
and FASTER, dammit" approach we have now.  And I'm more than happy to  
secede to those who have forgotten more scsi-fu than I will ever  
learn, I just hate magic numbers, that's all :)

-aDe