From owner-freebsd-current Sat Aug 26 15:31:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA04641 for current-outgoing; Sat, 26 Aug 1995 15:31:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA04634 for ; Sat, 26 Aug 1995 15:31:15 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id IAA19347; Sun, 27 Aug 1995 08:25:36 +1000 Date: Sun, 27 Aug 1995 08:25:36 +1000 From: Bruce Evans Message-Id: <199508262225.IAA19347@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, terry@cs.weber.edu Subject: Re: another 2.0.5 installation report Sender: current-owner@freebsd.org Precedence: bulk >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". Nope. It knows the BIOS geometry, sort of (+). The BIOS geometry is stored in bootinfo.bi_bios_geometry[] (*). The main problem is that this can't be used reliably until the mapping of BIOS drive numbers to FreeBSD devices is known. (+) Only the results of the int 0x13 BIOS call are known. This call only allows 10 cylinder bits, so the cylinder count is always wrong if there are more than 1024 cylinders. Some BIOSes truncate the count 1024. Others truncate it to 1023. The int 0x41 and int 0x46 vectors point to standard tables that allow up to 16 bits for the cylinder count, at least for the first 2 IDE drives. I think they work the first couple of SCSI drives too. (*) netboot doesn't initialize much of the bootinfo, in particular it doesn't initialize bi_bios_geometry[]. >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 This can be done in the boot loader. The boot loader needs to do it anyway, since it should handle your request to boot from sd127 when you have 128 SCSI drives and want to boot from the last 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. No thanks. I don't like unnecessary writes to key metadata, and I'd like to allow readonly root drives. >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. Nope. See partition.hlp. Bruce