From owner-freebsd-current Mon Nov 25 21:29:02 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10345 for current-outgoing; Mon, 25 Nov 1996 21:29:02 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA10335 for ; Mon, 25 Nov 1996 21:28:51 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA26908; Tue, 26 Nov 1996 16:20:06 +1100 Date: Tue, 26 Nov 1996 16:20:06 +1100 From: Bruce Evans Message-Id: <199611260520.QAA26908@godzilla.zeta.org.au> To: rgrimes@GndRsh.aac.dev.com, terry@lambert.org Subject: Re: 2.2-ALPHA install failure Cc: current@freefall.freebsd.org, darrylo@sr.hp.com, jkh@time.cdrom.com Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Or atleast make size == cyl * sec * head (ie 1024*64*255 == 16711680) >> my reasoning is that any third party fdisk program that sees the current >> bogus table likes to try and ``fix it'' and usually ends up doing quite >> the wrong thing : -(. > >This is bogus. > >Why can't I just ioctl the (unpartitioned) raw disk device and ask it? Because the driver doesn't know anything about the BIOS geometry. For SCSI drives, the ioctl returns the geometry reported by the SCSI MODE_SENSE command. This has nothing to do with the BIOS geometry, and can't be the same as the BIOS geometry even by accident for modern drives with an average of >= 64 sectors/track. The driver doesn't know anything about the BIOS geometry because it doesn't know the correspondence between BIOS drive numbers and FreeBSD drive numbers. The BIOS numbers depend on the POST order (see many old postings by Terry :-). Bruce