Bug #2746
open
The last cylinder of hard disks is inaccessible in IDE/ATA mode
0%
Description
This is based on testing on an HP N36L, BIOS O41, dated 30 Sep 2010.
In both OI148 and OI151a, the last cylinder of hard disks is inaccessible when the system BIOS's disk controller is set ATA/IDE mode. In AHCI mode, the entire disk is accessible.
Although the amount of inaccessible data is small, it was detected by a failure to correctly copy entire disks between two disk controllers. It is also possible that this might have an affect on the replacement of disks in zraid arrays if a replacement drive appears smaller than its predecessor.
Tests with NetBSD, gparted (Debian) and Spinrite show that these are all able to successfully access the last cylinder in IDE/ATA mode. Note that both OI148 (OpenSolaris kernel) and OI151a (Illumos kernel) failed the tests, but no other OS did so.
Testing was performed on a group of 3 Hitachi and 1 Seagate 250Gb drives, each having identical geometry: 488397168 sectors (484521 x 16 x 63) of 512 bytes.
Tests were performed using:
/usr/gnu/bin/dd if=/dev/rdsk/<drive>p0 of=/dev/null bs=516096 skip=484519
This should read two notional "cylinders" of 16x63x512 bytes. In AHCI mode, this is what happens, but in IDE/ATA mode, only one cylinder is read, and the last cylinder is inaccessible.
The identity of the inaccessible cylinder was confirmed as being the last one (no. 484521, as opposed to any other) by md5 checkums.
Disks were swapped between the 2 controllers on the server, and were confirmed to have the inaccessible cylinder whenever they were in IDE/ATA mode, on either controller.
Updated by Bayard Bell about 11 years ago
- Project changed from OpenIndiana Distribution to illumos gate
Updated by Granville Moore about 11 years ago
Ran the same test on OI151a3 (live USB version), with the same results - it also exhibits this bug.
Updated by Bill Kearney almost 11 years ago
I can confirm the same thing appears to be happening with two IDE connected drives on a Suprmicro X7DBE motherboard. These also being 250GB drives, WD
All other operating systems seem to be able to communicate properly with these drives, regardless of BIOS setting. Ubuntu, Windows 20008R2, ESXi, and Centos6. Since they're on a PATA port the BIOS doesn't have options on their configuration. The rest of the SATA ports do have BIOS options, but no settings appear to improve OI's handling of the drives.
Updated by Bill Kearney almost 11 years ago
Bill Kearney wrote:
These are 250GB drives, WD2500 3.5" PATA, listing 488397168 sectors
Updated by Bill Kearney almost 11 years ago
And to illustrate further, one of these drives reconnected via USB comes up perfectly. I simply unplugged the IDE cable and attached a USB adapter.
In 'iostat -E' the PATA connected one shows a size of 250058833920 bytes. That exact same drive reconnected on USB shows as 250059350016 bytes. That's a difference of 516096 bytes (/512 = 1008)
I only stumbled across this bug when attempting to set up a dual-boot scenario. Using the OI live CD the gparted program showed NO partitions on a drive that was just previous booted into Ubuntu. This makes for an easy way to see the problem, connect a PATA drive that has partitions on it, boot the live CD and then see if the partitions show up properly.
I have not experimented with other sizes of PATA drives, but can if there's interest.
Updated by Bill Kearney almost 11 years ago
Ok, so I went a step further and connected the drive via a SATA to IDE converter, into on of the motherboard SATA ports. Works great, size is reported the same as USB-IDE, and partitions are visible in gparted.
Going one step more, I did the same thing with a 160gb PATA drive, an Hitachi HDS7216. When connected via PATA it reports size as 160039305216. When connected via USB and SATA adapters it reports size as 160041885696, a difference of 2580480 bytes. Once again, when connected directly to the motherboard PATA interface the drive won't show proper partitions on gparted or fdisk. But when connected via USB or SATA adapters it works perfectly.
I'm guessing there might be some sort of CHS math nonsense going on here.
Seems a bit odd to have this problem on what ought to be some pretty well understood territory.