Date: Sun, 12 Dec 1999 18:40:28 -0800 (PST) From: klh@netcom.com To: freebsd-gnats-submit@freebsd.org Subject: kern/15447: Seagate ST32550 (Barracuda 2LP) may be a broken tagged queueing drive? Message-ID: <19991213024028.7522114D48@hub.freebsd.org>
index | next in thread | raw e-mail
>Number: 15447 >Category: kern >Synopsis: Seagate ST32550 (Barracuda 2LP) may be a broken tagged queueing drive? >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Dec 12 18:50:01 PST 1999 >Closed-Date: >Last-Modified: >Originator: Ken Harrenstien >Release: 3.1-RELEASE >Organization: >Environment: FreeBSD <hostname> 3.1-RELEASE FreeBSD 3.1-RELEASE #<n>: <buildstring> i386 >Description: A separate problem is causing my system to sometimes boot up with tagged queueing enabled and sometimes not. I've recently been stressing the disk significantly more than usual and have encountered user-level I/O errors that I traced back to the enabling of tagged queueing. With tagged queueing off, everything always works. With it on, a heavy load of seeks will cause reads and writes to start failing. I was able to verify this by running a test case on two ST32550s, both on line during the same kernel boot and both identical in all respects except that one had tagged queueing enabled and the other didn't (the randomness of this enabling is a separate problem). The drive without tagging always works perfectly; the drive with tagging always fails at random places during the test. I verified that it is not specific to the individual drives by doing reboots until the formerly tag-enabled drive booted up tag-disabled -- whereupon it then performed perfectly again. I also verified that the filesystems were identical by doing a complete track-by-track copy of one to the other prior to testing. The ST32550 is not in the latest quirks table in cam_xtp.c, although several other Seagates are. The Barracuda 2LP was at one time fairly popular so I'm a little surprised this hasn't shown up before, but who knows. Maybe most FreeBSD users have IDE drives. >How-To-Repeat: My test case consisted of saving a tar of /usr/src/sys in a partition about 1G distance away from /usr on the same drive, and attempting to restore to /usr from that. Tar encounters I/O errors attempting to restore perhaps 1% to 2% of the files. Once in a while the kernel will get a swap error and complain, but otherwise no diagnostics are shown on the console. >Fix: Obviously the ST32550 can be added to the quirks table in cam_xtp.c. I just hope this does not reflect some underlying problem with tagged queueing support of Seagates in general. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991213024028.7522114D48>