From owner-freebsd-hackers Fri Feb 5 20:06:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA19949 for freebsd-hackers-outgoing; Fri, 5 Feb 1999 20:06:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vespucci.advicom.net (vespucci.advicom.net [199.170.120.42]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19940 for ; Fri, 5 Feb 1999 20:06:34 -0800 (PST) (envelope-from avalon@vespucci.advicom.net) Received: from localhost (avalon@localhost) by vespucci.advicom.net (8.8.8/8.8.5) with ESMTP id WAA26877; Fri, 5 Feb 1999 22:06:27 -0600 (CST) X-Envelope-Recipient: freebsd-hackers@FreeBSD.ORG Date: Fri, 5 Feb 1999 22:06:26 -0600 (CST) From: Avalon Books To: Tony Overfield cc: FreeBSD Hackers Subject: Re: Unable to newfs HD >10G with 3.0 In-Reply-To: <3.0.6.32.19990204214937.00879b20@bugs.us.dell.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 4 Feb 1999, Tony Overfield wrote: > Well, have you seen a "newer PC" that doesn't implement INT 13 > extensions, or are you confusing what I said with some other problem > that you've seen? I am well aware that the INT 13 spec has been essentially obsolete for a long time. And it appears that we are in agreement regarding its use (or rather, its lack of use considering the newer drive interfacing). > I was assuming the devices are not known to be defective. All bets are > off for any *standardized* behavior of broken devices. Also correct. Rest assued, we give our supplied eight kinds of hell when what they send us isn't up to spec. > Then they must have really bunged it up. I've not seen such a problem > with any of the drive suppliers we use. We stopped seeing most of the screwy drive firmware about six months ago, though we do still see such things very occasionally. > There's no excuse for busted drive firmware, but you can't blame the > "8.4 GB solution" which, as I said, works correctly if implemented > properly. Again, you and I are in agreement. > You implied that there are a bunch of nonstandard solutions to this > problem, but that isn't true. I don't consider a bug in a particular > drive's firmware to constitute a "nonstandard implementation." In my > mind, and probably yours too, it is simply broken and needs to be > replaced. Well, this is best clarified by saying that "non-standard" isn't really a dirty word anymore, espcially when manufactures and programmers are willing to hammer out the details to make it work. But in the beginning, it was a real chore to find combinations of drives and BIOS's that worked properly. Luckily, these problems continue to diminish in magnitude--and this is a good thing (for us hardware types, in particular). --R. Pelletier Sys Admin, House Galiagante We are a Micro$oft-free site To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message