Date: Tue, 12 Nov 2002 02:16:56 -0800 From: ANYBODY <somebody@kashmir.etowns.net> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: scsi@freebsd.org Subject: Re: adaptec scsi - seagate da -- current Message-ID: <20021112101656.GA12579@kashmir.etowns.net> In-Reply-To: <20021111094918.GA5702@HAL9000.homeunix.com> References: <20021030095416.GA1840@hurd1.kashmir.etowns.net> <376290000.1035997229@aslan.btc.adaptec.com> <20021110081757.GA961@HAL9000.homeunix.com> <20021111094918.GA5702@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
hunh my problem seems to be pretty similar however it was happening because of extremely heavy tag depth ( > 200 ). after automatic adjustment it used to be around 63 so I manually forced it to be reduced to 60 at bootup by adding a command in /etc/rc.local camcontrol tags da0 -N 60 looks like around <= 16 would be a good number for your da0. MAKE SURE YOU HAVE READ MY PREV. THREAD COMPLETELY. exactly why this happens even though my hardware is not borderline.... is something that I havent yet figured.... tag depth is the amount of concurrency. It does not have to be over 200 for good performance. Matter of fact even 8,16 etc give a very reasonable performance. also make sure the scsi bus is properly terminated on ( and only on ) the 2 ends. you can use physical terminators at the 2 ends of the bus or have the last devices ( according to physical wiring ) set to use the internal terminators(if they have them). Its the same. Usually card is on 1 end and the drive on the other if all drives are internal and no external scsi device. Most cards have the option of enabling the terminator through the bios : make sure it is enabled (only if in your condition it is the last device on 1 end.). most cards and devices also support supplying power to a terminator outside (if you have an external terminator). (power to the bus) having a couple of devices supplying power to the bus if you have physical terms is ok. if no physical terminators make sure the internal terms are supplied with power. jumpers on the hard drives. look into the drive manuals. Seagate maintains extensive manuals on their website. seagate.com look around for disk encyclopaedia. I am not sure if quantum is a seagate product. Also people have reported that low level formatting some times helps -- if you can do it either from scsi bios or from freebsd...... I lost patience and dont think needed to either. Some scsi bios settings also contain some option for tag depths... I have seen atleast 1 if I remember correctly which is set to low usually. Hope this helps Let me know Best regards, Saurabh Gupta On Mon, Nov 11, 2002 at 01:49:18AM -0800, David Schultz wrote: > Thus spake David Schultz <dschultz@uclink.Berkeley.EDU>: > > I'm running into the same problems on a very light I/O load > > (running /usr/bin/less on certain files triggers it). There's > > also a timeout every time at bootup. I have included my dmesg > > below. > [...] > > Here's some additional information: > > # camcontrol inquiry da0 > pass0: <QUANTUM XP34550S LXY1> Fixed Direct Access SCSI-2 device > pass0: Serial Number PCB=2011303002 ; HDA=184715611932 > pass0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled > # camcontrol tags da0 -v > (pass0:ahc0:0:0:0): dev_openings 24 > (pass0:ahc0:0:0:0): dev_active 0 > (pass0:ahc0:0:0:0): devq_openings 24 > (pass0:ahc0:0:0:0): devq_queued 0 > (pass0:ahc0:0:0:0): held 0 > (pass0:ahc0:0:0:0): mintags 24 > (pass0:ahc0:0:0:0): maxtags 32 > > # camcontrol inquiry da1 > pass1: <QUANTUM VIKING 4.5 NSE 8808> Fixed Direct Access SCSI-2 device > pass1: Serial Number 174716034271 > pass1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled > # camcontrol tags da1 -v > (pass1:ahc0:0:1:0): dev_openings 253 > (pass1:ahc0:0:1:0): dev_active 0 > (pass1:ahc0:0:1:0): devq_openings 253 > (pass1:ahc0:0:1:0): devq_queued 0 > (pass1:ahc0:0:1:0): held 0 > (pass1:ahc0:0:1:0): mintags 2 > (pass1:ahc0:0:1:0): maxtags 255 > > It seems like da0 is the problem device. Just after it times out > now and then, camcontrol shows things like: > > # camcontrol tags da0 -v > (pass0:ahc0:0:0:0): dev_openings 22 > (pass0:ahc0:0:0:0): dev_active 2 > (pass0:ahc0:0:0:0): devq_openings 22 > (pass0:ahc0:0:0:0): devq_queued 0 > (pass0:ahc0:0:0:0): held 0 > (pass0:ahc0:0:0:0): mintags 24 > (pass0:ahc0:0:0:0): maxtags 32 > > # camcontrol tags da0 -v > (pass0:ahc0:0:0:0): dev_openings 16 > (pass0:ahc0:0:0:0): dev_active 8 > (pass0:ahc0:0:0:0): devq_openings 16 > (pass0:ahc0:0:0:0): devq_queued 0 > (pass0:ahc0:0:0:0): held 0 > (pass0:ahc0:0:0:0): mintags 24 > (pass0:ahc0:0:0:0): maxtags 32 > > It seems like da1 is fine, but then again I use that drive less > heavily. 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?20021112101656.GA12579>