Date: Sun, 16 Mar 1997 17:02:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703170002.RAA06819@phaeton.artisoft.com> In-Reply-To: <199703162244.JAA17242@godzilla.zeta.org.au> from "Bruce Evans" at Mar 17, 97 09:44:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >How does fdisk use it? Just to determine where cylinder boundaries > >exist? (i.e. so partitions are an integral multiple of cylinder size?) > > fdisk presents it as a default if the disk doesn't already have a > (reasonable) partition table on it. This seems to mainly confuse > users :-(. It later uses the geometry that the user set or accepted > to write the CHS values. Garbage geometry -> garbage CHS values -> > unbootable partitions and probably a different garbage geometry for > the default next time. Q: Why are the users permitted to override geometry? A: Because FreeBSD sometimes gets it wrong. Q: Why does FreeBSD sometimes get it wrong? A: Because FreeBS gets the INT 13 values in the boot loader, but then discards them in favor of the potentially incorrect CMOS and/or non-BIOS drive query return values. Q: Why does FreeBSD do this? A: No one knows. > >Again, the IPL stuff comes from the disk using the BIOS/"system ROM" > >geometry, right? > > What's IPL? No, FreeBSD doesn't use the geometry reported by the BIOS > except to print a table of BIOS geometries when it is booted with -v, > and in some kludgy cases (see above). It doesn't know the correspondence > between BIOS drives numbers and FreeBSD drive names, so it can't look up > its table of BIOS drive geometries to get the BIOS geometry (if any) > corresponding to each FreeBSD drive. IPL = Initial Program Load. It's an IBM term. There is also the (general industry standard) RPL or "Remote Program Load". Typically, if a card has a ROM slot, there is an RPL ROM available for it. Most point of sale systems use RPL instead of IPL to remove hardware components from the cash registers, etc.. I think that the correspondance can be largely established between BIOS device and FreeBSD device using sector counts from protected mode calls vds C*H*S from the BIOS. In the case where they are equal, it doesn't matter. Where it seems to matter, you can look for the FreeBSD partition, the DOS boot block to find the boot device, or, if all else fails, ask the user (instead of asking by default). The correspondance problem is the hardest to solve, given the 7k or so second stage BIOS boot block limit. > >No one (with the exception of fdisk?) *should* need to know the real > >geometry, right? And, it could possibly be argues that fdisk/newfs > >only "need" to know it for "performance" reasons, right? > > Yes. No/yes. fdisk needs to know if for constructing bootable MBRs. Also if it is writing C/H/S values for use by the DOS MBR to get to the BSD second stage boot, since the DOS MBR (incorrectly) looks at the C/H/S values instead of the LBA values (since the DOS MBR has the DOS geometry available, factoring an LBA to a C/H/S value is easy for it to do, but it is too badly designed to do that). In some respects, if our boot block would modify the LBA values to match the C/H/S values, while still in real mode, we would be much happier. Tony Overfield (an engineer from Dell) has gone over this all before, but since he wants a three stage boot, a lot of his good comments were thrown out with the bathwater of a three stage boot after no one came forward to "bell the cat" (write the three stage boot code). Regards, Terry Lambert terry@lambert.org --- 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?199703170002.RAA06819>