Date: Sat, 26 Aug 95 15:39:29 MDT From: terry@cs.weber.edu (Terry Lambert) To: freebsd-current@FreeBSD.org Subject: Re: another 2.0.5 installation report Message-ID: <9508262139.AA16296@cs.weber.edu> In-Reply-To: <199508262052.WAA17362@uriah.heep.sax.de> from "J Wunsch" at Aug 26, 95 10:52:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> It's an IDE translation, btw. Anyway, you've been missing my point. > In one occasion, sysinstall errouneously prevented me from using the > inner partition as root, even though it would have been possible. I guess the question here is "how is FreeBSD supposed to know the BIOS translation being used so that it can enforce the right behaviour". The answer is "it can't unless it does it's own I/O via the BIOS instead of a protected mode driver -- it can only guess". Your problem seems to be that it is guessing wrong for you; any suggestions on how it can be made to guess correctly? The only one I can see is providing a VM86() fallback driver, doing INT 13 AH=0x8n for all drives, and then MD5 checksumming areas of each disk so that they can be matches to the same areas checksummed after having been read by the protected mode driver. Even then, some of the techniques described below would be needed to avoid potentially confusing the driver with backup partitions that MD5 out to the same numbers. Remember that the BSD driver can't convert the C/H/S values from the partition table into sector offsets -- or convert a setor offset into a C/H/S value -- without knowing the translation being applied by the controller to C/H/S values presented by the BIOS. Remember further that though the BIOS geometry of the drive can be potentially determined from the drive paramter area in low core or elsewhere, there is no way to ensure that the INT 13 hook order for the drives is the same as the protected mode driver probe order. That is, I can find out the translation for drive 0x80, or even 0x8n for an INT 13 AH=8 call to the BIOS that hooks for the particular drive ID I am interested in, but there is no way for me to match that up with the drives that respond to BSD's probe requests from the protected mode driver. The INT 13 hook order for, for instance, two AHA1542CF controllers, or an IDE controller and a 1542CF controller (which is what determines the BIOS drive ID's attached to each controller) is dependent on POST routine card initialization order. The order BSD's protected mode drivers present to the kernel is based on the probe order, which is base on the order the controllers appear in the conf file used to build the kernel. Further, even if the orders were identical, and controllers in the config were put there in slot initialization order (which is not identical from motherboard to motherboard), there are some controllers that would hook INT 13 and have BIOS support for which there are no BSD drivers available. Now although Adaptec allows otherwise, the boot order in BIOS by default without tweaking the factory defaults on your Adaptec will be BIOS drive ID 0x80 followed by ID 0x81. This is the same problem with the "boot from second drive" that the MBR replacements face. Once the kernel is up, how can it identify the drive that it was loaded from other than via BIOS drive ID? The typical approach is to go through the attached controllers attached drives one by one until you find a BSD partition ID and assume that that's the one. An extra "fix" of making sure the partition is marked active is probably a good idea. Actually, a date stamp in the disklabel written by the MBR replacement when it is used to boot a BSD drive would probably be best, with a probe search that goes through all possible BSD partitions looking for the most recent timestamp. This isn't done currently, and still would not work in all cases anyway; see below for "why not?". > In another case, it didn't tell me anything, but i finally got stuck > with an unusable root file system, since it was in the second FreeBSD > slice, and sysinstall attempted to newfs in the `compatibility' slice > (which is the same the boot loader would use). I don't recognize the term "compatability slice". I assume you mean that it newfs'ed the DOS slice or something? The above linear search and disklabel timestamp would mostly fix this case, though you would potentially be screwed on a reinstall. > I guess the above is totally unrelated to the magic 1024 cylinder > number, sysinstall _intents_ to be smart about the problems with the > compat slice, but it's got it wrong (decision being made based on the > location of the data cylinders on the disk, instead of based on the > fdisk slot # as it ought to be -- remember, the compat slice it the > first FreeBSD slice as seen in the fdisk table). The fdisk slot number is supposedly meaningless (ie: the DL register is not loaded for all BIOS'es). Perhaps you have a POST initialization order that hooks INT 13 in a different order than the BSD probe order, or you have one of these badly behaved (usually AMI, I think) BIOS implementations for the default controller? 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?9508262139.AA16296>