Date: Fri, 16 Jun 95 20:00:34 MDT From: terry@cs.weber.edu (Terry Lambert) To: aflundi@sandia.gov (Alan F Lundin) Cc: freebsd-hackers@freebsd.org Subject: Re: HD Geometry dirty trick Message-ID: <9506170200.AA14001@cs.weber.edu> In-Reply-To: <199506162115.PAA17715@sargon.mdl.sandia.gov> from "Alan F Lundin" at Jun 16, 95 03:15:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Does this mean that it's possible that every distinct > > > BIOS could produce a different geometry for a given disk > > > drive, so that there is no way to predict via an algorithm > > > for all machines what the BIOS geometry should be? Bummer! > > > > Yes. Generally, it's on a per controller ROM revision basis, and > > is not specific to internal machine BIOS. It gets the general name > > of "BIOS" because the POST routines on the card point the INT 13 > > interface to their own ROMs, replacing/chaining the default BIOS. > > > > And there's no way to ask... there's a way to figure it out that mostly > > works, but which can run into LCF problems. > > If there's no way to ask, how does DOS do it? DOS *always* communicates via INT 21 calls (the file I/O interface) or INT 13 calls (the raw disk interface). INT 21 is a consumer of INT 13. Since the translation is done by software at INT 13, DOS never has a problem. Our problem comes from teh fact that we are a protected mode OS and so do not use the INT 13 interface (you can only make BIOS calls from protected mode if you have a protected mode BIOS or if you use a virtual x86 -- VM86 -- interface). The problem with a quick VM86 hack is that it would not fix the problem entirely, since the INT 13 is hooked in BIOS POST initialization order, and there's no way to ask it what it is. At that point, we would know the fictitios geometries of all devices, but we (still) would not be able to match the BIOS devices to the BSD devices (which show up in probe order). To complete the fix requires two pieces: the first is a "fallback" driver that uses a VM86 to do all of its disk I/O, period. This will acause BSD to work on all hardware DOS works on, though some issues of secondary drives will exist. Specifically, if two controllers have BIOS translations active, there will be an issue of figuring out devices after the first two on the controller. The second piece is a crc (or other mechanism) to ask the disks which is which by comparing their contents. Obviously, this would not fit in the current bootblocks. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506170200.AA14001>