Date: Wed, 2 Apr 1997 08:31:59 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, 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: <199704021532.IAA07133@seagull.rtd.com> In-Reply-To: <199703171835.LAA08169@phaeton.artisoft.com> from "Terry Lambert" at Mar 17, 97 11:35:00 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. > > > > This is not answering the question. > > Yes it is. If FreeBSD did not discard the boot loader values, it would I *still* fail to see why the drive isn't left INITted the way it already *has* been INITted -- i.e. why these values are discarded. And, why is it necessary to "pair up" an already INITted drive with it's FBSD counterpart? > have the "correct" geometry for the device. The "correctness" of the > geometry is a result of: > > 1) Being able to determine the absolute sector offset for a > given C/H/S value in the partition table. > > 2) Being able to, from protected mode, write a DOS partition > table C/H/S value so that when the DOS MBR goes to that > C/H/S location and reads a track, it gets the FreeBSD second > stage boot. > > 3) The FreeBSD kernel (which should use the LBA address, not > the C/H/S address) being able to turn the C/H/S address > back into an absolute sector offset. I had assumed that this would be the "easy" way to "equalize" all translation schemes. However, apparently this is not a universally implemented feature (?) > > > Q: Why does FreeBSD do this? > > > A: No one knows. > > > > Several, perhaps even many people know. Some of these have tried to explain > > the problem, but it would appear that you don't actually want to know the > > answer. > > > > One answer is that the values returned by the int13 call in the bootloader > > may not match the actual layout of the disk. The CMOS values allow the > > user to override a BIOS that might be getting it wrong. The direct drive Hmmm... I hadn't seen how the CMOS parameters factored into this. I was under the impression that the BIOS would INIT the drive using these CMOS parameters (e.g., "user defined geometry") > > query allows a properly-configured disk to be moved from one system to > > another with a reasonable chance of it still working. Hmmm... why are the "direct drive query" parameters "correct"? In my case, they aren't. > As long as you have no other OS's on the drive which don't re-INIT > the drive as well. Perhaps I'm misunderstanding this comment. While FBSD is running, no "other OS" *can* reINIT the drive, right? So, is this the same as my statement that if another OS *cohabits* the drive with FBSD, then you have a (potential) problem? > > It is not sensible to try to match sector counts against c/h/s values > > from the BIOS in many cases; often the discrepancy can be more than > > one track multiple out. A signature approach might perhaps be better. > > o Multiply the C/H/S geometry of the INT 13 ID's in question by > the C/H/S limit values to get the absolute drive size. Compare > the size against the IDENTIFY size. This will establish disk > identity in the vast majority of cases. > > o Multiply the C/H/S geometry of the INT 13 ID's in question by > the C/H/S value from the partition table for bootable OS types, > starting with FreeBSD and MS OS's, and look for the "bootable > signature" word that the DOS MBR looks for to establish disk > identity. This will cover the vast majority of the remaining > cases. > > o Modify the second stage boot to fill in the correct LBA address > in the DOS partition table for a given C/H/S value at boot time; > have BSD *always* use the LBA values in protected mode and > *always* use the C/H/S values in the INT 13 using boot code. > This should cover all other cases except where the drive is > identical. > > o When the drive is identical, ask the user the first time the > protected mode kernel is run, before root is mounted, which > device is correct. Record this value in the "bootbias" in > the second stage boot block *after* a successful mount of > the root FS. Never ask again(*). > > (*) Ideally, this last would not be necessary if the root > mount modifications I submitted in June of 1994 were > integrated, since multiple root mounts could be attempted, > and the one which was successful could be taken as the > right one. In the case of identical disk devices, the > "last mounted" time stamp should be examined, and the most > recent one taken, and/or the drive serial number should be > recorded in the boot block and retrieved using IDENTIFY or > SCSI operands on the devices before they are booted, so > that subsequent mounts following a duplication including > timestamp would not fail. (sigh) Perhaps this would make sense to me if I understood why the "need" to match BIOS devices with FBSD devices... Sorry, when I originally started this thread, I thought it was a "simple little thing" (TM Reg.) <:-( --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021532.IAA07133>