Date: Mon, 17 Mar 1997 11:04:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dgy@rtd.com (Don Yuniskis) Cc: terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703171804.LAA08120@phaeton.artisoft.com> In-Reply-To: <199703170237.TAA17617@seagull.rtd.com> from "Don Yuniskis" at Mar 16, 97 07:37:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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...)? Yes. They are no longer accessable. Or, in particular, you are not able to make INT 13 calls once you are in protected mode because there is not VM86() support for doing so. As Bruce explained, there is no way to establish a correspondance between BIOS device number (for which you have obtained a BIOS geometry, the "correct" geometry) and a FreeBSD device. What he didn't explain is that this is because the BIOS device order is a result of BIOS POST order for the controllers and the devices, which hook INT 13, and the FreeBSD device order is a result of probe order, generally a result of the config file lines with which the kernel is built. Because people plug things into the bus in whatever order they feel like, there is no way to buld a kernel that is guaranteed to probe devices in the same order that INT 13 is chained. As a matter of fact, you can't even guaranteed that a device with an INT 13 chain-in even *has* a FreeBSD driver at all, so you may be out of order no matter what you do (this is why I'm always calling for "a fallback driver using VM86()"). > > 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? Yes, that's true; coeexistance is impossible. Tony Overfield of Dell has stated in no uncertain terms that FreeBSD is incapable of installing on an increasing number of Dell systems because of this discrepancy (which arises out of big disks and their use of the "service pack 2" (OEMSR2) Win95 VFAT32 code). They *require* INT 13 LBA INIT'ing of the drive. The reason there *should* be a difference is explained above: we can't tell which INT 13 drive ID goes with which disk probed by FreeBSD. > > The correspondance problem is the hardest to solve, given the 7k or > > so second stage BIOS boot block limit. > > [I'm lost, here... <:-( ] See above. 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?199703171804.LAA08120>