Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Sep 1998 10:13:40 +0200
From:      Stefan Eggers <seggers@semyam.dinoco.de>
To:        Michael Class <michaelc@hpbbse.bbn.hp.com>
Cc:        current@FreeBSD.ORG, seggers@semyam.dinoco.de
Subject:   Re: CAM and quantum disc 
Message-ID:  <199809230813.KAA06752@semyam.dinoco.de>
In-Reply-To: Your message of "Tue, 22 Sep 1998 23:03:53 %2B0200." <Pine.HPP.3.94.980922230258.9329A-100000@hpbbse.bbn.hp.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> (da1:ncr0:0:1:0): tagged openings now 18
> (da1:ncr0:0:1:0): tagged openings now 17
> (da1:ncr0:0:1:0): tagged openings now 16
> 
> The disk is a "Quantum XP34300W L915".
> 
> I remember that I read about these things before on this list.
> Do we need a quirk entry like for the other quantum disks in cam_xpt.c
> to restrict the number of tagged queue entries?

It looks strange that it drops down one by one as from reading what
the -current list said it sounds like it will notice the limit as soon
as it exceeds it, issue just one message and then it's done for the
rest of the uptime.  Am I (with just EIDE disks for now) right about
this for the usual behavior of CAM?

Are there any ill effects from the drive doing it one by one?  Maybe
the drive is just a bit slow in answering back for this problem, gets
filled with lots of transfer requests from our CAM subsystem and then
for each of the requests it can't handle sends an error message back.
CAM interprets this one by one and while doing so issues all these
messages.

Does such a behavior really warrant an entry in the quirks list?  If
it works perfect otherwise and once stabilized is silent I don't think
it's really necessary.  One could change CAM to postpone the reporting
a little bit and see if it gets even lower in an attempt to combine
them to just one message.

Stefan.
-- 
Stefan Eggers                 Lu4 yao2 zhi1 ma3 li4,
Max-Slevogt-Str. 1            ri4 jiu3 jian4 ren2 xin1.
51109 Koeln
Federal Republic of Germany

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809230813.KAA06752>