Date: Mon, 14 Feb 2000 07:37:47 -0700 From: "Justin T. Gibbs" <gibbs@FreeBSD.org> To: Chris Johnson <cjohnson@palomine.net> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@FreeBSD.org, lamaster@nren.nasa.gov Subject: Re: BT-948 timeouts Message-ID: <200002141437.HAA00367@caspian.plutotech.com> In-Reply-To: Your message of "Thu, 10 Feb 2000 04:55:43 EST." <20000210045543.A57016@palomine.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>Thanks very much for your response. > >Here's what I did: > >su-2.03# camcontrol tags da0 -N 8 > >And here's the result: > >su-2.03# camcontrol tags da0 -v >(pass0:bt0:0:6:0): dev_openings 8 >(pass0:bt0:0:6:0): dev_active 0 >(pass0:bt0:0:6:0): devq_openings 8 >(pass0:bt0:0:6:0): devq_queued 0 >(pass0:bt0:0:6:0): held 0 >(pass0:bt0:0:6:0): mintags 2 >(pass0:bt0:0:6:0): maxtags 255 > >This seems to have done the trick. I built a world without any timeouts, which >I hadn't been able to do before I made the change. > >Is there a fancy way to make this change survive across boots, or should >I just shove the camcontrol command in a script that runs at boot time? You can add a quirk to sys/cam/cam_xpt.c for your drive that will limit the number of tags to use. >How would I go about learning what the tags setting should be for a particular >drive? CAM can determine the maximum number if you attach the drive to a controller that will report the QUEUE FULL status (ahc, sym, ncr, aic). When the system stops reducing the number of tags (while the device is under a heavy transaction load), you know that you've found the device's limit. >Chris > -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002141437.HAA00367>