From owner-freebsd-current Mon Nov 25 10:18:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27424 for current-outgoing; Mon, 25 Nov 1996 10:18:52 -0800 (PST) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA27404 for ; Mon, 25 Nov 1996 10:18:43 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id SAA28507 for ; Mon, 25 Nov 1996 18:17:44 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 25 Nov 1996 18:17:24 +0000 Received: from tees.elsevier.co.uk (tees.elsevier.co.uk [193.131.197.60]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id SAA06314; Mon, 25 Nov 1996 18:17:18 GMT Received: (from dpr@localhost) by tees.elsevier.co.uk (8.8.3/8.8.3) id SAA08704; Mon, 25 Nov 1996 18:16:05 GMT To: Bruce Evans Cc: current@freebsd.org, fenner@parc.xerox.com Subject: Re: 2.2-ALPHA install failure References: <199611232119.IAA05102@godzilla.zeta.org.au> From: Paul Richards Date: 25 Nov 1996 18:16:04 +0000 In-Reply-To: Bruce Evans's message of Sun, 24 Nov 1996 08:19:46 +1100 Message-ID: <57ohgmniqj.fsf@tees.elsevier.co.uk> Lines: 51 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > This behaviour is very natural if you know that there are only 6 sector > bits, 8 head bits and 10 cylinder bits. Values larger than 1023/255/63 > get truncated mod 1024/256/64 in each field. Geometries which would > cause truncated sector or head bits must not be used. Truncation of > cylinder bits is usually harmless provided you don't want to boot from > a partition above cylinder 1023 or run a lesser O/S that doesn't support > such partitions. A colleague here that I just co-erced into switching from SCO to FreeBSD (Ok, didn't take that much effort) has had some problem that I'm still collecting info on but basically, it seems that he had set the number of cylinders in his BIOS to some large value and that SCO had written a MBR that had used the full number of bits from the BIOS for the number of cylinders (i.e. without truncation) and from our initial guess and put FF's into the other MBR entries. FreeBSD isn't seeing the partitions on the the end of the disk because our bootblock masks the high bits of the no. cylinder field from the BIOS (perfectly correctly as per spec) so FreeBSD has a weird idea of things since SCO wrote the MBR and cheats by using the all the bits the BIOS sends provides it. He's going to provide more complete details. > Flexible SCSI BIOS geometries also cause interesting bootstrapping > problems. Suppose that the geometry is initially 64/32 for some reason, > but you don't want that. You run fdisk and tell it the geometry that > you want (normally 255/63) and then change the partition table, being > careful to end partitions on (new) cylinder boundaries. The kernel will > detect the changed geometry in some circumstances. The SCSI BIOS will > detect on the next boot. However, if you make a mistake with the > cylinder boundaries, then the SCSI BIOS might detect garbage and switch > to a default that might not work. It's safest to reboot immediately and > check that the changes worked right. Hmm, can't the driver contain this knowledge? i.e. the driver could export it's default geometry to userland so libdisk knows what the default geometry for that controller is and use it in preference to guessing. DOS never seems to have these problems and when I run into difficulties I usuall stick a small DOS partition on the disk to get a valid MBR. I assume it's just letting the controller pick a default. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155