From owner-freebsd-stable Tue May 26 15:53:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12452 for freebsd-stable-outgoing; Tue, 26 May 1998 15:53:18 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA12398 for ; Tue, 26 May 1998 15:53:03 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA01571; Tue, 26 May 1998 14:46:58 -0700 (PDT) Message-Id: <199805262146.OAA01571@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Nate Williams cc: Mike Smith , Michael Robinson , freebsd-stable@FreeBSD.ORG Subject: Re: Bug in wd driver In-reply-to: Your message of "Tue, 26 May 1998 09:02:19 MDT." <199805261502.JAA05071@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 May 1998 14:46:58 -0700 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > > > >> I wrote a message related to this problem to freebsd-questions > > > >> yesterday, but upon further investigation, I have decided this is > > > >> a bug, not a feature. > > > > > > > >Actually, it's almost certainly a hardware fault. > > > > > > Actually, the bug is that the driver does not recover gracefully from a > > > recoverable hardware fault. It instead goes into an infinite loop, taking > > > significant pieces of the kernel with it. > > > > Actually, an interrupt timeout is not a "recoverable hardware fault". > > Sure it is. You're being silly now Mike, this is indeed a 'bug' in the > driver, but it's probably not one that's going to be fixed unless the > submitter fixes it himself. Fixing it is non-trivial but possible to > do. I guess it's a matter of semantics. You're suggesting we should have a workaround, which is fair enough. I'm inclined to think that if your hardware screws that badly you're better off losing it. > Having a bad spot on a disk shouldn't make the disk *totally* unusable, > as every other 'significant' OS can deal with fine. This isn't a "bad spot" in the traditional sense - this is the disk firmware failing. A "bad spot" gives you a recognisable, and recoverable, error. We handle that just fine. What we don't handle are cases where the disk:controller protocol fails. IMHO, the value in handling this case is small - the only times I've seen this reported over the last few years has been with disks that are basically screwed. Note that DOS-derived operating systems will often dump their cookies in a similar fashion under the same circumstances (exact results seem to vary, and I don't have a drive I can test this with anymore, having consigned my last one to the dump before moving). > This is also why I was w/out a laptop for 5 months, since our driver > couldn't get past the bad sector on the boot partition when it went bad > and everytime fsck tried to read it it locked up the computer. :( So don't fsck it; I talked you through solving that problem, and you ignored me. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message