On Tue, 9 Sep 2003, at 12:17:54, Mark Terribile wrote:
Well, I've got my 120G disk up and running and
now I'd like to understand something odd.
I went into /stand/sysinstall to put down the
partition and slice tables and the FS and found that
it determined the geometry (cyl/head/sectors) as
15107/255/63 . Since it warned that the values must
match the BIOS values, I set them to the 59131/16/255
that the BIOS reports. It rejected this entry and
went back to its own. I also tried the values
reported
by the ata driver on startup; these too were rejected.
Since it's working (with about 117G -- that's
Gi_b_abytes) it must be OK (famous last words!) but
what's going on here? Why does it demand the values
reported by the BIOS if it will refuse them, and why
does the driver come up with another set of values,
also unacceptible to the disklabel/fdisk machinery?
I expect that most people reading this are aware of some of the
limitations of BIOS disk addressing, including the physical disk
addresses in the disk partition table in the MBR (master bootstrap
record) of bootable PC disk drives which allocates only 10 bits for
the cylinder number, 8 bits for the head number, and 6 bits for the
sector number. There is also a Fixed Disk Drive Parameter Table
available through the traditional BIOS. The table format allocates
16 bits for the number of cylinders, 8 bits for the number of heads,
and 8 bits for the number of sectors per track. Since BIOS sector
numbers begin at one (not zero), the BIOS addressing limitations are
usually given as 1024 cylinders, 255 heads, and 63 sectors per track.
(Note: 1024*255*63 sectors is just under 8GB.)
The ATA/IDE specifications limit you to 65535 cylinders, 16 heads,
and 255 sectors per track (see http://www.t13.org). If you accept
both sets of limitations at once, you get a maximum of 1024 cylinders,
16 heads and 63 sectors, resulting in the infamous 528 MB hard
disk size limitation.
In an effort to work around this unacceptable limitation, your
BIOS may pretend that your disk drive has some other geometry,
typically using 255 heads and 63 sectors per track though other
fake geometries are sometimes used. When a program uses the
traditional BIOS system call to do disk I/O (machine instruction
int 13 with a small function code 0x16 in the AH register),
it must use the same disk geometry that is used by the BIOS for
interpreting disk addresses. Otherwise the BIOS might translate
the specified physical disk address into the wrong actual disk
address.
(Note: there are also Enhanced Disk Drive Services (EDD) using
AH register function codes =0x40 which have bigger limitations and
might support Logical Block Addresses (LBA) instead of physical disk
addresses. EDD is also described at http://www.t13.org. I don't
know which BIOS/bootstrap programs support/use EDD. Modern BIOS
presumably provides EDD services. It doesn't do you any good if
your BIOS supports EDD but your bootstrap program doesn't use it.
The FreeBSD minimal bootstrap that just boots the active partition,
/usr/src/sys/boot/i386/mbr/mbr.s, appears to use EDD services when
available. The booteasy program that allows you to specify a
desired partition via a function key, which may be the program
.../tools/srcs/bteasy/BOOT.ASM in your FreeBSD distribution, does
not seem to use EDD services. (I am not certain that this is the
bootstrap installed by /stand/sysinstall.) The GRUB bootstrap
program (in /usr/ports/sysutils/grub) appears to use both EDD
services and LBA when available.)
The only way to discover the geometry expected by the BIOS is to
ask the BIOS. This is no problem for bootstrap programs and some
Microsoft operating systems that use the BIOS disk services for
all disk I/O, but the BIOS services cannot be used by a real
operating system after it takes over the interrupt and virtual
memory management hardware and possibly trashes the data structures
built by the BIOS during POST (Power On Self Test). A BIOS service
routine is likely to do things unacceptable to a real OS, such
as screwing with system hardware configuration registers or going
into indefinite spin loops waiting for device register bits to
change.
The FreeBSD /stand/sysinstall and fdisk programs need to use the
BIOS disk geometry when constructing MBR partition tables. It would
be nice if the kernel could get this information from the BIOS early
in the bootstrap process and stash it somewhere for further reference,
but this seems not to be a FreeBSD kernel feature. The fdisk and
/stand/sysinstall programs apparently try to guess the BIOS disk
geometry and then ask the user for the correct geometry. It would
only be fair if the man pages for those programs told you *how*
to determine the correct geometry.
Some BIOS self-configuration programs (what you boot when holding
down the DEL key) may tell you about some ATA/IDE drives, but I am
not sure I trust them. One BIOS gives me a choice of three
