Large HD, old BIOS

bscott at ntisys.com bscott at ntisys.com
Mon May 3 10:18:00 EDT 2004


On Sun, 2 May 2004, at 9:24pm, colet at code-energy.com wrote:
> I bought a motherboard, cpu and memory off a friend (P3 based).  When I
> got the system put together, the BIOS (which I did flash to the latest
> version) only seems to recognize it as a 8.5 GB drive.  However, even
> though the BIOS only sees it as such, several of the distributions I've
> tried see that it is indeed a 200GB drive.

  There are several places you can encounter limits: The disk controller
itself, the system BIOS, and the OS.  Multiple limits can pile up.

  The reasons for these limits are usually fairly arbitrary.  For example,
you can hit all sorts of things which just assume drives will never have
more then X of one thing or another (sectors per track, cylinders per head,
heads, total sectors, total bytes, etc., etc.).  These can often be fixed
via a simple update or patch, be it to firmware or software.  Of course,
there is no guarantee that a given vendor will bother to release an update.  
It may be that your motherboard's vendor has EOL'ed the product and you're
stuck with a semi-broken BIOS.

  There is another limit one should be aware of, though, that is rather
harder to get around.  The original spec for ATA says that LBA (Logical
Block Addressing) uses a 22-bit field.  That works out to 128 GB (128 * 2^30
= approx 137 billion bytes).  Drives bigger then that use an extension for
44-bit LBA.  Patching for 44-bit LBA is generally a lot harder -- impossible
if it's a hardware limit in a disk controller.

  I can also envision the following scenario: The kernel talks to the IDE
device and gets a capacity report of 200 GB; however, the disk controller is
incapable of actually handling transfer requests for blocks above 128 GB.  
Just because the kernel thinks it can see the whole disk doesn't mean it can
access the whole disk.  I do not know enough about IDE internals to know if
this scenario can actually happen, but if it can, it would certainly add to
the confusion.  You could test this by running "badblocks" on the disk in
question.

  As far as the BIOS vs Linux thing goes: The Linux kernel almost completely
ignores the BIOS.  For example, if you set the BIOS HD type to "None", Linux
will still find it (assuming you can get the kernel booted).

  The boot loader is the only place where the BIOS really matters.  The BIOS
has to find and load the boot record.  The code in the boot record has to
load any additional boot loader code, and that has to find, load, and boot
the kernel and initrd (if any).  All that has to be done using the BIOS.  
So a BIOS problem can easily kill the boot loader.

  You can often work around BIOS limits by putting the boot loader within
the part of the disk that the BIOS can access.  This typically means
creating a small (10 MB or so) /boot partition at the start of the disk.  
However, one can also run into problems where the disk that the Linux kernel
sees is not the same disk the BIOS sees -- geometry translation is not
always consistent.

  Also, check the jumpers on the hard disk.  Some HDs can be set to lie
about their capacity, in order to workaround BIOSes which lock-up when
presented with disks beyond certain limits.

  If you have one, you can try an add-in PCI IDE controller card, which will
bypass mainboard controller and BIOS problems.  You can purchase such
controllers for less then $50.

> Despite this however, I can't seem to get the boot loader to cooperate.

  Information, please.  Which boot loader, and what version?  What behavior
do you see?  What error message(s), if any, and when?  What distro and
release?  What kernel version?

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |




More information about the gnhlug-discuss mailing list