Date: Wed, 24 Dec 1997 23:45:22 -0500 From: Bryan Batten <BryanBatten@compuserve.com> To: Doug White <dwhite@resnet.uoregon.edu> Cc: Questions for FreeBSD <freebsd-questions@FreeBSD.org> Subject: Re: Detecting 3rd IDE Drive Message-ID: <199712242346_MC2-2D24-246D@compuserve.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712242346_MC2-2D24-246D>