RE: IDE "logical" geometry & partition tables (problem with 2.4k erne l, also seems to apply to 2.6)

From: Stuart_Hayes
Date: Thu Oct 23 2003 - 10:06:41 EST

By "correct", I meant that the geometry matches what the BIOS expects when
doing int13 calls. If the partitions are not set up with this geometry,
then an MBR/bootloader that uses CHS to access the drive will not be able to
boot. This problem only came to my attention because of an instance where
such an MBR is used.

>> If a partition table is then created on the drive using this
>> the CHS values in the partition table will not be correct.

> "correct" has no meaning here.

-----Original Message-----
From: Andries.Brouwer@xxxxxx [mailto:Andries.Brouwer@xxxxxx]
Sent: Wednesday, October 22, 2003 3:42 PM
To: B.Zolnierkiewicz@xxxxxxxxxxxxxx; Hayes, Stuart
Cc: Andries.Brouwer@xxxxxx; linux-ide@xxxxxxxxxxxxxxx;
Subject: Re: IDE "logical" geometry & partition tables (problem with 2.4
kerne l, also seems to apply to 2.6)

On Wednesday 22 of October 2003 00:00, Stuart_Hayes@xxxxxxxx wrote:

> I have discovered a problem with how Linux determines IDE disk
> (BIOS) geometry.

The concept of logical geometry is slowly vanishing.

Supporting it is impossible, but there were some attempts,
and in the 2.0, 2.2, 2.4, 2.6 series each kernel drops
some of the contortions present in previous versions.

I wrote long stories in
and even more in various replies to questions like this one,
but the easiest point of view is "geometry does not exist".

> If an IDE hard drive has no partition table when Linux is booted,
> *and* if the hard drive is on a PCI IDE controller (a controller
> that isn't at I/O address 1f0h), *and* if the drive doesn't support
> 48-bit addressing, Linux will just use the geometry that is reported
> by the drive in with the "identify device" command, rather than
> getting the geometry used by the IDE BIOS by doing an int13 function 8
> call.

"Linux will just use" - but roughly speaking Linux never uses the geometry,
there is no need for a concept like that. Fortunately, because there is
no such thing, so we would have problems if it were actually needed.

"Roughly speaking": user space can ask for a geometry using HDIO_GETGEO
and then gets some random #cyls / #heads / #secs/track. Also - in some
cases the "last cylinder" plays a role, and of course nobody knows where
that is unless disk size and geometry are given.

Asking the BIOS is one of the attempts at support. It fails in many ways.
One reason is that the correspondence between BIOS devices and kernel
devices is unknown - so if we do an INT 13 call for device 0x80, for which
device do we get data? hda? hdb? sda?
Also, the BIOS may allow us only to inquire about the first two disks.

Since the kernel does not use this info, and only transmits it to fdisk
and LILO, and fdisk and LILO need slightly different information anyway,
there is no good reason to keep this code in the kernel.

Finally, things can be forced on all levels. The kernel has boot parameters
telling it what to reply to HDIO_GETGEO. And LILO and fdisk have command
parameters that allow the specification of a geometry.
And no geometry is needed at all with LILO "linear" or "lba32" and
with fdisk on a disk larger than 8 GB.

> If a partition table is then created on the drive using this geometry,
> the CHS values in the partition table will not be correct.

"correct" has no meaning here.

"geometry" is not a property of the disk, but of CMOS, BIOS, OS.

> I would think that the best solution

But is there a problem?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at