From owner-freebsd-questions Wed Dec 24 20:53:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA22314 for questions-outgoing; Wed, 24 Dec 1997 20:53:17 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from arl-img-6.compuserve.com (arl-img-6.compuserve.com [149.174.217.136]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22133 for ; Wed, 24 Dec 1997 20:46:52 -0800 (PST) (envelope-from BryanBatten@compuserve.com) Received: (from mailgate@localhost) by arl-img-6.compuserve.com (8.8.6/8.8.6/2.9) id XAA01574; Wed, 24 Dec 1997 23:46:15 -0500 (EST) Date: Wed, 24 Dec 1997 23:45:22 -0500 From: Bryan Batten Subject: Re: Detecting 3rd IDE Drive To: Doug White Cc: Questions for FreeBSD Message-ID: <199712242346_MC2-2D24-246D@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id UAA22304 Sender: owner-freebsd-questions@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Merry Christmas!!! On Mon, 22 Dec 1997, you wrote: > > regardless of which controller the 2.1G drive is connected to, the > > BIOS > > fails to autodetect. > > *THAT* is your problem. FreeBSD will go *nowhere* if the BIOS can't > see > it!!! > > I suggest returning your disk. Something must be wrong with it. According to Micro Firmware (www.firmware.com/pb4ts/over2gb.htm), the problem is that Phoenix BIOS as of 4.03 doesn't use enough bits in CMOS RAM to properly hold the disk parameters for IDE drives over 2GB, even though the drive itself does properly autodetect. This problem applies to Phoenix BIOSes prior to 4.03.6.08 released 6/28/96. As I stated previously, once Linux is running, everything's OK. I have filesystems mounted on it and use it in every way as a standard drive. So I know the drive is really OK. What I've done is to buy a 1G drive that my BIOS does operate correctly with, and use that. Sure enough, FreeBSD finds out about it OK. So, as far as I'm concerned, this problem is resolved. > Linux must have a super-agressive IDE controller probe to find > something > even the BIOS can't. Linux's philosophy is to totally ignore the BIOS as soon as possible - i.e. as soon as code which is loaded by the BIOS - and hence can rely on it to at least get to the drive from which it loaded that code - has got all of itself in. (Editorial) In my opinion, this is a better policy, because it shields the OS from problems associated with the vagaries of old BIOSes in systems which are being upgraded on a piece by piece basis. Given the hacker propensities which motivate someone like me to install FreeBSD on his own system, this seems to be the preferable approach, and I think FreeBSD would improve its competitiveness and interoperability by doing likewise. An additional reason for trying for BIOS independence is that its easier to fix problems if the offending code is part of a software distribution that can be modified, rather than BIOS PROM code - which is much more difficult to fix. The counter arguments, of course, are that: As systems with old BIOSes get older, they get fewer; so this is a self correcting problem. In the meantime, staff resources are limited, and there are other things to do. However, I would point out that using the BIOS restricts addressability to - at best - 24 bits of block addresses using Extended CHS addressing. Using LBA mode, you can get 32 bits of block addresses. And if anything is certain, it is that the number of blocks on EIDE drives will eventually expand beyond what 24 bits can address. (end Editorial) Again, thanks for your responsiveness, and - again - Merry Christmas and Happy New Year! Bryan