> Basically there are *no* problems with large disks.
Well, I just helped someone get Linux to use the last 4G of his 12G
disk, and fdisk wouldn't recognize them automatically (I had to tell it
the number of "bios" cylinders), so there *is* a problem.
Yes, of course you are right. But note my `basically'.
[I have always to fight people who have lots of problems
introduced by themselves. If the idea you have at the back
of your mind is that all should be easy, then you try a few
easy things and it works. If the idea you have at the back
of your mind is that big disks give lots of complications,
then you try lots of very complicated things and get more and
more confused, confirming the idea that it is really complicated.]
Now suppose you start with the idea that there is an easy
solution that does not involve kernel patches or talking
about the geometry to kernel or fdisk or LILO.
Then what can you do?
For example, go into the BIOS setup, set this disk to Normal
(and not Large, or LBA or so). Voila! Everything works.
Roughly speaking there are two issues with > 8.4 GB disks.
The first is that they report 16383/16/63 regardless of the
actual size. The kernel was fixed in 2.0.34 (by testing for this
exact triple).
The second is that the BIOS may be unaware of the first issue
and present us with a translated version of this 16383/16/63.
(Many people think that LBA means Linear Block Addressing and is
a Good Thing. That is true, but in the BIOS Setup it stands for
something entirely different, some translation scheme, which is
a Bad Thing, to be used in emergency cases only, like when you
have the Gates virus.)
The kernel is 2.0.36, unpatched.
Yes. I suppose Alan will put my patch, or something similar,
in 2.0.37. My 2.0.36a source reads (ide.c)
/* calculate drive capacity, and select LBA if possible */
capacity = current_capacity (drive);
/* Set the cylinder count - the BIOS reported value may be too small */
if (drive->bios_sect && drive->bios_head)
drive->bios_cyl = capacity / (drive->bios_sect * drive->bios_head);
His bios does LBA, so the Linux kernel has no problem accessing sectors
above 8G.
Linux does not use the BIOS. It can access the entire disk
regardless of the BIOS you have.
However, the C/H/S reported by the bios is 1024/255/63, while
C/H/S reported by the IDE probe is 25113/16/63. The former is saved for
fdisk's benefit, but should be corrected to 1575/255/63.
Yes, precisely.
I've tried with 2.2.0-pre9, and it gets this right.
Yes.
Here's a patch for 2.0.36 that makes it work in this special case.
Disclaimer: This patch works for me and should be safe, at least for
"normal" situations (I don't know about disk managers).
--- ide.c.org Sat Jan 23 01:42:35 1999
+++ ide.c Sat Jan 23 01:55:04 1999
@@ -2585,6 +2585,19 @@
if (drive->sect == drive->bios_sect && drive->head == drive->bios_head) {
if (drive->cyl > drive->bios_cyl)
drive->bios_cyl = drive->cyl;
+
+ /* same, when the bios value is as big as it can be, but the ide
+ * probe didn't return the same number of heads -orabidoo
+ */
+ } else if (drive->sect == 63 && drive->head == 16 &&
+ drive->bios_sect == 63 && drive->bios_head == 255 &&
+ drive->bios_cyl == 1024) {
+
+ unsigned long my_cyl = drive->cyl * 16 / 255;
+
+ /* more than 128G (ide limit) => probably bogus */
+ if (my_cyl > 1024 && my_cyl < 16384)
+ drive->bios_cyl = my_cyl;
}
if (!strncmp(id->model, "BMI ", 4) &&
Yes, that is more or less correct. But not good enough:
For example, I have also seen BIOSes that produce 1027/255/63
probably because they compute 16383*16/255 = 1027.
(And I say `more or less' also because I think - but may be mistaken -
that in the presence of disk managers the Right Thing is to return a
geometry that shows a total disk size that is the physical size minus
the space taken by the disk manager. The capacity = current_capacity ()
above takes care of that. But I have very little experience with
Disk managers.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/