From owner-freebsd-scsi Fri Nov 1 20:27: 4 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 E807537B401 for ; Fri, 1 Nov 2002 20:27:02 -0800 (PST) Received: from kashmir.etowns.net (dsl-65-184-96-65.telocity.com [65.184.96.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C0143E88 for ; Fri, 1 Nov 2002 20:26:56 -0800 (PST) (envelope-from somebody@kashmir.etowns.net) Received: from hurd1.kashmir.etowns.net (hurd1 [192.168.0.41]) by kashmir.etowns.net (8.12.6/8.12.6) with ESMTP id gA24QnaW013534; Fri, 1 Nov 2002 20:26:50 -0800 (PST) (envelope-from somebody@kashmir.etowns.net) Received: (from somebody@localhost) by hurd1.kashmir.etowns.net (8.12.6/8.12.6/Submit) id gA24Ql9J000900; Fri, 1 Nov 2002 20:26:47 -0800 (PST) Date: Fri, 1 Nov 2002 20:26:26 -0800 From: ANYBODY To: mikes@siralan.org, somebody@kashmir.etowns.net Cc: Nate Lawson , gibbs@scsiguy.com, scsi@freebsd.org Subject: Re: adaptec ahc : seagate da : current Message-ID: <20021102042626.GA739@hurd1.kashmir.etowns.net> References: <20021101011945.GA56589@hurd1.kashmir.etowns.net> <20021102003806.GA1664@hurd1.kashmir.etowns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021102003806.GA1664@hurd1.kashmir.etowns.net> User-Agent: Mutt/1.5.1i 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, Nov 01, 2002 at 04:38:06PM -0800, ANYBODY wrote: > On Fri, Nov 01, 2002 at 12:11:08PM -0800, Nate Lawson wrote: > > On Thu, 31 Oct 2002, ANYBODY wrote: > > > > this drive? According to the controller, the drive is failing > > > > to respond to a whole slew of commands that we have queued to > > > > it. You might have better luck if you reduce the tag depth > > > > to the disk via camcontrol. > > > > > > > > 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! IMHO Saurabh Gupta To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message