Date: Wed, 2 Apr 1997 08:03:09 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: terry@lambert.org (Terry Lambert) Cc: dgy@rtd.com, terry@lambert.org, bde@zeta.org.au, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199704021503.IAA05043@seagull.rtd.com> In-Reply-To: <199703171804.LAA08120@phaeton.artisoft.com> from "Terry Lambert" at Mar 17, 97 11:04:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Terry Lambert said: > > > > 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 Ahhhh... OK. *That* makes sense. I guess I had blindly assumed drives were logically tied to particular controller addresses, etc. (i.e. the "MASTER" IDE drive on the controller at 0xXXX is drive Y, the "SLAVE" drive on that same controller is drive Y+1, etc.) > 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()"). Presumably, INT13 is hooked in "slot order"? > > > 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. I still don't see why there "should" be the difference. The only reason (and I'm not trying to belittle this at all...) I can see that you would *not* want to use the geometry that the (IDE) drive has been initted to (by the "BIOS") would be to be able to support drives that the BIOS *can't*. But, you would do this at the expense of not being able to have DOS coexist with FBSD on those drives (that's still my impression -- though I could be quite wrong). --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021503.IAA05043>