Hi,
the harddisk geometry recognized by 2.6 kernels differs from the geometry
recognized by 2.4 kernels. The 2.4 kernel version agrees with the BIOS and
fdisk/parted. The 2.6 kernel version seems senseless to me. Here is a diff
between bootup messages: (more info available if you need it)
--- /var/log/boot.msg24 2004-04-01 10:33:23.000000000 +0200
+++ /var/log/boot.msg26 2004-04-01 10:34:48.751069936 +0200
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
loop: loaded (max 16 devices)
-Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
+Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
-VP_IDE: IDE controller at PCI slot 00:07.1
+VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100%% native mode: will probe irqs later
-ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
-VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
+VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
ide0: BM-DMA at 0xa400-0xa407, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xa408-0xa40f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DTLA-307030, ATA DISK drive
-blk: queue c03e66c0, I/O limit 4095Mb (mask 0xffffffff)
-hdc: TOSHIBA DVD-ROM SD-M1402, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
+hdc: TOSHIBA DVD-ROM SD-M1402, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
-hda: attached ide-disk driver.
-hda: host protected area => 1
-hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100)
-ide-floppy driver 0.99.newide
-Partition check:
+hda: max request size: 128KiB
+hda: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hda: hda1 hda2 hda3
ide-floppy driver 0.99.newide
Especially interesting are the lines:
-hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100)
+hda: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
You can see that both share the same sector count, but differing Megabytes
and differing CHS. This breaks nearly every partitioning program I know
and it makes supporting old ATARAID configurations a nightmare. (Some of
the RAID superblock locations depend on the BIOS idea of CHS.)
Is this change intentional or a bug?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
On Thu, 01 Apr 2004 16:45:15 +0200 Carl-Daniel Hailfinger wrote:
> the harddisk geometry recognized by 2.6 kernels differs from the geometry
> recognized by 2.4 kernels. The 2.4 kernel version agrees with the BIOS and
> fdisk/parted. The 2.6 kernel version seems senseless to me. Here is a diff
> between bootup messages: (more info available if you need it)
[skip]
In fact, this did not work correctly even in 2.4, except in some very
limited circumstances: either hda only, or hda+hdb. Even hda+hdc
configuration was broken (hda was getting parameters from BIOS, but
hdc was not).
> You can see that both share the same sector count, but differing Megabytes
> and differing CHS. This breaks nearly every partitioning program I know
> and it makes supporting old ATARAID configurations a nightmare. (Some of
> the RAID superblock locations depend on the BIOS idea of CHS.)
Again, this was broken in 2.4.x too, except for the first IDE drive.
Difference in Megabytes is probably due to rounding and should not
matter (this is output only).
Sergey Vlasov wrote:
> In fact, this did not work correctly even in 2.4, except in some very
> limited circumstances: either hda only, or hda+hdb. Even hda+hdc
> configuration was broken (hda was getting parameters from BIOS, but
> hdc was not).
What do MS-DOS and Windows do in the hda+hdc case?
-- Jamie
Carl-Daniel Hailfinger <[email protected]> writes:
> Hi,
>
> the harddisk geometry recognized by 2.6 kernels differs from the geometry
> recognized by 2.4 kernels. The 2.4 kernel version agrees with the BIOS and
> fdisk/parted. The 2.6 kernel version seems senseless to me. Here is a diff
> between bootup messages: (more info available if you need it)
[snip]
> Especially interesting are the lines:
> -hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100)
> +hda: 60036480 sectors (30738 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
>
> You can see that both share the same sector count, but differing
> Megabytes and differing CHS. This breaks nearly every partitioning
> program I know and it makes supporting old ATARAID configurations a
> nightmare. (Some of the RAID superblock locations depend on the BIOS
> idea of CHS.)
>
> Is this change intentional or a bug?
Hard to say. The whole notion of "geometry" is a little confused
these days. The geometry shown by the 2.6 kernel is consistent with
that reported by the "extended INT13" BIOS interface, which allows 16
bits for each of C/H/S. This is, in some sense, the "real" geometry.
The other geometry, which happens to be the one you need if you plan
to interoperate with other operating systems, is reported by the
"legacy INT13" BIOS interface. This interface allows only 10 bits for
the cylinder count (and has no "linear" mode), so modern BIOSes
typically "lie" and report large head and sector counts to allow more
of the drive to appear within the first 1024 cylinders.
The 2.6 behavior was causing a headache for me, so I fixed it.
First, I wrote a patch for the Linux EDD module and sent it to the
maintainer (Matt Domsch at Dell). He cleaned it up and submitted it
to Andrew Morton, who sent it to Linus. It is included in 2.6.5-rc*.
So begin by updating to a 2.6.5-rc* or -mm* kernel. Load the EDD
module ("modprobe edd").
This will create entries under /sys/firmware/edd/int13_dev80. The
entries I added are named "legacy_cylinders", "legacy_heads", and
"legacy_sectors". These merely reflect the geometry reported by the
legacy INT13 interface.
Ignore the cylinder count. Read the head count (H) and sector count
(S). Increment H by one (long story).
Read /sys/block/hda/size, and divide that by S and then by H to
produce a cylinder count (C).
Finally, run a command like this:
echo "bios_cyl:C bios_head:H bios_sect:S" > /proc/ide/hda/settings
...where C, H, and S are as computed. This will reset the values
which the kernel reports in HDIO_GETGEO, causing your partitioning
tools to produce results the same way DOS fdisk would (which is, of
course, what you want).
Works for me; see <http://unattended.sourceforge.net/>.
Note that simply assuming H and S are 255 and 63, respectively, will
usually work but not always. IBM Thinkpads, for instance, use H=240.
- Pat