MFC of "Large set of CAM improvements" breaks I/O to Adaptec 29160 SCSI controller

[Alexander Motin]

Scott Long wrote:
> On Apr 29, 2010, at 10:56 PM, Alexander Motin wrote:
>> Scott Long wrote:
>>> On Apr 29, 2010, at 7:47 AM, Robert Noland wrote:
>>>> Scott Long wrote:
>>>>> On Apr 29, 2010, at 2:50 AM, Pete French wrote:
>>>>>>> Thanks. First step successful - I can steadily reproduce problem on
>>>>>>> CURRENT. raidtest with 200 I/O streams over gmirror of two disks on same
>>>>>>> channel triggers issue in seconds. Any I/O on channel dying after both
>>>>>>> disks report "Queue full" error same time. The rest of system works
>>>>>>> fine. If I preliminarily manually adjust queue depth of one disk -
>>>>>>> everything works fine. I'll investigate it tomorrow.
>>>>>> Glad you have managed to dupliate it - the queue depth thing is
>>>>>> inetersting, what changes did you make ? I can try them here and see
>>>>>> if they improve the situation on either of my two machines.
>>>>>>
>>>>> For the record, queue-full is a common, expected condition in CAM.  It's not something that should be avoided =-)
>>>> Should we maybe have a counter in sysctl rather than flooding the console with these messages then?
>>> That's a pretty good idea.  I'll make it happen.
>> It is already hidden behind bootverbose. Hiding it deeper will make
>> unclear why CAM requeues the rest of commands (also reported under
>> bootverbose). I've tuned log messages a bit recently and they seem to be
>> more consistent and readable now IMHO.
> 
> We used to run FreeBSD at Yahoo with bootverbose turned on in order to help with debugging.  After years of doing this, I finally turned bootverbose off last year, partially because of the excessive console spam produced by these queue-full messages.  Even when we were writing the ahc/ahd drivers at Adaptec years ago, I never really liked these messages, and we rarely ran with bootverbose turned on unless we were actively developing code or debugging a problem.  I like Robert's suggestion because not only does it make running with bootverbose less painful, it can also provide counters and also calculate and report rate measurements that might be more useful than just the printf.
> 
> If you feel strongly against it, I won't push it, but I do like the suggestion.

No. I just wanted to say that requeue messages massively logged in that
case are even less informative for regular user.

-- 
Alexander Motin