Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Apr 2010 23:07:15 -0600
From:      Scott Long <scottl@samsco.org>
To:        Alexander Motin <mav@FreeBSD.org>
Cc:        freebsd-scsi@FreeBSD.org, FreeBSD Stable <freebsd-stable@FreeBSD.org>, Pete French <petefrench@ticketswitch.com>, Robert Noland <rnoland@FreeBSD.org>
Subject:   Re: MFC of "Large set of CAM improvements" breaks I/O to Adaptec 29160 SCSI controller
Message-ID:  <221F6444-3102-4CD7-A1A7-1DF4352E7F50@samsco.org>
In-Reply-To: <4BDA6310.10902@FreeBSD.org>
References:  <E1O7PS0-00093c-9M@dilbert.ticketswitch.com> <BCD96E46-A669-457D-A3A4-4F2E6F84E6A8@samsco.org> <4BD98DE2.8020703@FreeBSD.org> <4A883035-3570-4FCC-B8EB-F205BD6D640D@samsco.org> <4BDA6310.10902@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>>=20
>>> 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.
>>>>>=20
>>>> For the record, queue-full is a common, expected condition in CAM.  =
It's not something that should be avoided =3D-)
>>> Should we maybe have a counter in sysctl rather than flooding the =
console with these messages then?
>>=20
>> That's a pretty good idea.  I'll make it happen.
>=20
> 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.
>=20

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.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?221F6444-3102-4CD7-A1A7-1DF4352E7F50>