From owner-freebsd-scsi Fri Nov 1 21: 7:49 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA7DB37B401 for ; Fri, 1 Nov 2002 21:07:47 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 69A7243E6E for ; Fri, 1 Nov 2002 21:07:43 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 98480 invoked by uid 1000); 2 Nov 2002 05:07:44 -0000 Date: Fri, 1 Nov 2002 21:07:44 -0800 (PST) From: Nate Lawson To: ANYBODY Cc: scsi@freebsd.org Subject: Re: adaptec ahc : seagate da : current In-Reply-To: <20021102042626.GA739@hurd1.kashmir.etowns.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 1 Nov 2002, ANYBODY wrote: > On Fri, Nov 01, 2002 at 04:38:06PM -0800, ANYBODY wrote: > > On Fri, Nov 01, 2002 at 12:11:08PM -0800, Nate Lawson wrote: > > > Have you done what he said? man 8 camcontrol (see the "tags" subcommand). > > > > > > -Nate > > > > > > > Sorry dont know how but missed it. thank you for reminding. > > here is what I got: > > # camcontrol tags da0 -v > > (pass0:ahc0:0:3:0): dev_openings 63 > > (pass0:ahc0:0:3:0): dev_active 0 > > (pass0:ahc0:0:3:0): devq_openings 63 > > (pass0:ahc0:0:3:0): devq_queued 0 > > (pass0:ahc0:0:3:0): held 0 > > (pass0:ahc0:0:3:0): mintags 2 > > (pass0:ahc0:0:3:0): maxtags 255 > > > > ---- > > looks like i can set the dev_openings & devq_openings > > to anywhere between 2 and 255, with it being 63 now. > > I have no idea as to what, if at all would be a better > > number. any suggestions? > > Question does the kernel change these values dynamically > > perhaps as a result of the errors like the ones I am getting? > > If not howcome the problem occurs only if there is a little > > over moderate disk activity within probably a short while > > after bootup, and inspite of howmuch activity occurs later > > this problem most rarely occurs again. > > thanks and appreciate your help > > Saurabh Gupta > > > > Answering my own question : > these values are indeed dynamic in a running system. > the cam driver or the kernel keeps negotiating! > @least thats what I found after picking the numbers > every few seconds for an hour. > during bootup my numbers were 255 for the dev*openings > and that is when the drive gets into trouble. > If the activity is mild in the begining(bootup) the > stable dev*opening values are probably negotiated down > smoothly in a little while......and when the > understanding of a stable number is low enough the > drive doesnt get stuck anymore. > I guess I should go read the camcontrol driver in > detail before sounding off my opinion anymore > or risk being one of the BLIND men trying to FEEL an > elephant! Yes, the values are dynamically backed off as necessary. To avoid the timeout, set the maxtags lower via adding the appropriate camcontrol to rc.local. You can get a good idea on the lower bound for your drive by what it is dynamically resized to. FYI, even a tag depth of 8 allows for significant concurrency. But do some performance testing to see what works for you. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message