From owner-freebsd-hackers Wed Apr 2 07:33:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA04907 for hackers-outgoing; Wed, 2 Apr 1997 07:33:47 -0800 (PST) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA04898 for ; Wed, 2 Apr 1997 07:33:37 -0800 (PST) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id IAA07133; Wed, 2 Apr 1997 08:32:00 -0700 (MST) From: Don Yuniskis Message-Id: <199704021532.IAA07133@seagull.rtd.com> Subject: Re: wd driver questions To: terry@lambert.org (Terry Lambert) Date: Wed, 2 Apr 1997 08:31:59 -0700 (MST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De In-Reply-To: <199703171835.LAA08169@phaeton.artisoft.com> from "Terry Lambert" at Mar 17, 97 11:35:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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