On Sun, 2 May 2004, at 9:24pm, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> | 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. | _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
