Date: Mon, 17 Mar 1997 11:35:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) 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: <199703171835.LAA08169@phaeton.artisoft.com> In-Reply-To: <199703170311.NAA06131@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 17, 97 01:41:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Q: Why are the users permitted to override geometry? > > A: Because FreeBSD sometimes gets it wrong. > > That's accurate, but incomplete and misleading. FreeBSD sometimes gets it > wrong because it's not possible to always get it right. Bullshit. It is possible to get it right. You may have to rewrite a scratch area of a disk in order to do it, but it's possible. Windows95 does it just fine. It may be accurate to state that "it's hard for FreeBSD to get it right, but with slight modifications, FreeBSD could get it right in the vast majority of cases, and appeal to the user for the rest. I'm sure that this will come down to machines with identical drives that someone has duplicated with dd and which have identical defect lists for whatever reason. An unlikely case. > > 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 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. > > 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 > query allows a properly-configured disk to be moved from one system to > another with a reasonable chance of it still working. As long as you have no other OS's on the drive which don't re-INIT the drive as well. If you have read the VFAT32 specification that came on the OEMSR2 CDROM from Microsoft, you know that the code looks at the partition data of the disk in order to determine the geometry (just like the NCR BIOS does in order to make other SCSI controller geometries OK for the NCR controller). > > 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). > > This is not true. > > It is not safe to call int13 from protected mode. It is not safe to call > most of the BIOS at all without a real-mode 'penalty box' in which you > try to look as much like CP/M as possible. See OS/2 for an example of > doing this right. The INT 13 in question is called in the FreeBSD second stage boot block after switching back to real mode for the call (this is an artifact of the MACH boot blocks, which could switch back to real mode without penalty). Check the boot block code if you don't believe me. > 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. > The correspondence between FreeBSD device and BIOS device is only > significantly relevant with a mixture of SCSI and IDE devices, or > multiple SCSI devices on multiple controllers. It's relevant when there are two or more devices in the system which may be identical except for the INT 13 drive ID. > > Tony Overfield (an engineer from Dell) has gone over this all before, > > but since he wants a three stage boot, a lot of his good comments > > were thrown out with the bathwater of a three stage boot after no > > one came forward to "bell the cat" (write the three stage boot code). > > Several of us are playing with three-stage bootcode. If you would be so > kind as to contribute an ELF loader that understands your segment-colouring > stuff, preferably as an 'ld.so' for the kernel, we could move to a > boot-time link approach which could take advantage of this. What's wrong with Erich's code to do this? > In reality, two versions of the linker will be required; a very stupid > version that can load the main kernel object and some set of stipulated > objects for inclusion in the stage-3 bootstrap, and a smarter one that > should be part of the kernel to replace the current LKM mechanism. > > The 'stupid' one would need to fit inside the 64K small-model kernel > loader module. I don't see why the stupid one could not be the same as the smart one, as long as you were willing to establish PM mappings for it. As for segment loading, the most interesting method would be to put modules in seperate ELF segments in the kernel image itself, jamming them in or yanking them out at will. The segment coloring is only useful in this case if your defautl drivers for the console, etc. are colored differently than the rest of the kernel to allow them to be distinguished (and dumped at will for replacement). Given this, then a "boot" coloring (see the Microsoft Developer Network document on the Portable Executable format for ELF segment coloring) could get loaded leaving the rest for later. If you read the Schulman book on Win95, this is actually how Windows95 loads its VXD's and other pieces... only we don't have an IO.SYS that understands our file system (well, we don't have a publically available one, anyway). 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?199703171835.LAA08169>