Date: Mon, 17 Mar 1997 13:41:10 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: bde@zeta.org.au, dgy@rtd.com, hackers@FreeBSD.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703170311.NAA06131@genesis.atrad.adelaide.edu.au> In-Reply-To: <199703170002.RAA06819@phaeton.artisoft.com> from Terry Lambert at "Mar 16, 97 05:02:52 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > 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. > 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. > 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. > 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. 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. 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. > 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. 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. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703170311.NAA06131>