From owner-freebsd-stable Mon Aug 3 11:13:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10082 for freebsd-stable-outgoing; Mon, 3 Aug 1998 11:13:33 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from seedlab1.cropsci.ncsu.edu (seedlab1.cropsci.ncsu.edu [152.1.88.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10070 for ; Mon, 3 Aug 1998 11:13:17 -0700 (PDT) (envelope-from bsdbob@seedlab1.cropsci.ncsu.edu) Received: (from bsdbob@localhost) by seedlab1.cropsci.ncsu.edu (8.8.8/8.8.8) id OAA18430; Mon, 3 Aug 1998 14:08:17 -0400 (EDT) (envelope-from bsdbob) From: "Robert D. Keys" Message-Id: <199808031808.OAA18430@seedlab1.cropsci.ncsu.edu> Subject: Re: WD errors In-Reply-To: from Brian Tiemann at "Aug 3, 98 09:52:53 am" To: btman@ugcs.caltech.edu (Brian Tiemann) Date: Mon, 3 Aug 1998 14:08:15 -0400 (EDT) Cc: chrisj@outcast.media-net.net, freebsd-stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 3 Aug 1998, Chris wrote: > > > within the last week i have been running into problems when the system > > will go idle. It will still take something like telnet/http/ftp..... > > > wd0: status 80 error 80 > > > wd0s1f: wdstart: timeout waiting to give command reading fsbn 3148892 of > > 3148892-3148893 (wd0s1 bn 3689468; cn 229 tn 167 sn 62)wd0: status > > 80 error 80..... > I had that same thing happen to me, on a 2.2.2-RELEASE system. I > went through all sorts of theories, from heat problems on the disk itself > (it often wouldn't mount on boot after this until I'd put the disk in the > freezer for an hour or so), to a flaky power supply, to just really bad > luck with disks (this happened to a Seagate Medalist and then a WD Caviar > disk sequentially). That sounds VERY familiar..... > Eventually I went and got an all-SCSI system with a UPS; I'm > currently thinking that the errors are resulting from a bad IDE > controller, and here's why: On the 2.2.2 system, I did a bad144, and it > told me that something like 90% of my disk had bad blocks-- it bailed out > after only getting about 36% through the disk. So I assumed the disk was > fried... I took it home and put it in a DOS box, ran the WD tools on it > (which does a surface scan and general hardware diagnostic)... and it > found no errors whatsoever. > > So whatever the problem was, it's my old machine's hardware. So > I'd venture that you might have a flaky IDE controller there. I had similar sorts of problems using some cheap clone motherboards (the baby xt sized things from mainland China, in particular). They were VERY sensitive to the controller speed capability, and if I was not careful, they would bomb out. I sense it has a bit to do with clocking speeds on the bus, since that helped cure it on one board. I had similar sorts of problems with power supply brownouts using a tape drive that pushed the limit of the power supply in the chassis a little too closely. It wrote strange things in the IDE drive, that eventually caused it to fail. My expectation is that the ide badsector tables were overwritten in part on the brownouts. The power supply thing is very unpredictable. If you run out of power and it browns out, strange things can happen. Now I mount the tape drives externally with their own power supplies, and that seems to cure most of that kind of brownout problem, if the power supply is marginal. If the HD is on its last legs, sometimes it can be resurrected with the Seagate IDE formatting utility (available from their archives and I think from the oakland msdos archives). It has allowed me to recover most bellyup IDE drives, since it actually does a real LLFMT on the drives. It takes forever to run though (sometimes DAYS). It works on all kinds of IDE drives if you set the parameters manually. IF it is a random intermittent problem, suspect the motherboard or controller. IF it is an intermittent problem that hits when drives access suspect the power supply. Good Luck RDK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message