hysteresis for CAM_RESRC_UNAVAIL

[mjacob at freebsd.org]

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

Oh, I agree with you on that.

Yes, duplicated code is a PITA for sure. Okay- I'll redo this with a 
tunable and send out again. Should I include BUSY status as well?

-matt