Date: Sun, 16 Mar 1997 19:37:40 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: terry@lambert.org (Terry Lambert) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703170237.TAA17617@seagull.rtd.com> In-Reply-To: <199703170002.RAA06819@phaeton.artisoft.com> from "Terry Lambert" at Mar 16, 97 05:02:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Terry Lambert said: > > > >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. Yes, I don't understand why FBSD can't just use the same geometry settings that boot.c deduces? Are the BIOS ROMs no longer accessible once boot() has completed (sorry, my ignorance is showing...)? > 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 Sorry. Days long ago with punched paper tape and hollerith cards :-( > (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). Why *should* there be a difference? I would assume that you would err on the side of adhering to the BIOS geometry -- wouldn't adopting some *other* geometry make it tough (impossible?) to have a DOS partition on the same drive as FBSD and be able to *access* that DOS partition from FBSD? > The correspondance problem is the hardest to solve, given the 7k or > so second stage BIOS boot block limit. [I'm lost, here... <:-( ] > > >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). I think this is the problem I've currently been having -- DOS thinks the drive is 611/16/63 but FBSD reINITs it to 790/15/57. It's been tough trying to get DOS and FBSD to fit onto the same drive... > 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). Ah, you must find Jerry for that task (of "Tom and Jerry" cartoon fame!) ;-) --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703170237.TAA17617>