Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Aug 1997 07:58:33 +0200
From:      j@uriah.heep.sax.de (J Wunsch)
To:        freebsd-hackers@FreeBSD.ORG (FreeBSD hackers)
Cc:        imp@rover.village.org (Warner Losh)
Subject:   Re: fdisk and BIOS
Message-ID:  <19970820075833.RL47401@uriah.heep.sax.de>
In-Reply-To: <E0x0s58-00019Q-00@rover.village.org>; from Warner Losh on Aug 19, 1997 11:28:38 -0600
References:  <19970819080618.XR34263@uriah.heep.sax.de> <E0x0gTW-0000Rt-00@rover.village.org> <E0x0s58-00019Q-00@rover.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
As Warner Losh wrote:

>   From memory the disk drive reported
> 901c 5t 53s in demsg.  fdisk reported 785c 8h 56s for both the BIOS
> numbers and the incore numbers.  Once I set the numbers to the ones
> listed first (901, etc), fdisk reported 2047c 3h 34s for both the BIOS
> and the in core numbers.  Rebooting got me back to fdisk reporting the
> 785c figures, even though dmesg continued to report the 901 numbers
> (which agree with the Quantum ProDrive LPS numbers on the Quantum web
> page).  This is wd1, if that matters (and yes, it is jumpered to be
> slave).  More details when I can get to the machine again and run a
> script.  None of the numbers fdisk reported matched wd0's geometry.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No numbers could match any actual geometry these days, unless your
number of sectors per track is not constant.  But how are you gonna
tell this to fdisk. :-)

> Also, the BIOS was configured with type 47 - 901 5 53 for this drive
> (this is an old 386 that I got at a garage sale).

So if the BIOS uses 901*5*53, this is the correct value, and that's
also the reason why the disk reports it this way in the probe message.

I'm not sure where fdisk gets its weird numbers from, but maybe
there's a garbage fdisk table influencing all this.  It's always a
good idea to completely invalidate the fdisk table (dd if=/dev/zero
of=/dev/rwd1 count=20), then perhaps even reboot (so the slice code in
the kernel won't see a valid table at all).  Try running fdisk
afterwards.

I'm too lazy to review all relevant code parts now, in order to make a
prediction what would happen where. :)

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970820075833.RL47401>