2.2.18 and Maxtor 96147H6 (61 GB)
Quoted 6 lines · Igmar Palsenberg
Quoted 5 lines
kernel 2.2.18 hates my Maxtor drive :
hda: Maxtor 96147H6, 32253MB w/2048kB Cache, CHS=65531/16/63, (U)DMAActual (correct) parameters : CHS=119112/16/63
No. 2.2.* handles large drives since 2.2.14.
This looks more like you used the jumper to clip the drive to 32GB. Don't use it and get full capacity.
If your BIOS hangs when it sees such a large drive so that you cannot avoid using the jumper, use setmax in your boot scripts, or use a kernel patch that does the same at kernel boot time.
Quoted 1 line
Quoted 1 line
Looks like some short int (2 bytes) overflowing. I'll try the ide patches.
The overflow is in certain BIOSes, not in Linux. (You see in the above: 65531 is not an overflow value.)
Sven Koch replied:
Quoted 2 lines
I had to recompile fdisk as my old suse 6.4 version got the same 2byte-wraparound problem.
In the good old days the HDIO_GETGEOM ioctl would give you the disk geometry. It has a short for cylinders and hence overflows when C gets above 65535. Since geometry is on its way out - indeed, there has not been any such thing for many, many years - it would have been nonsense to introduce new ioctls that report meaningless 32-bit numbers instead of the present meaningless 16-bit number.
So, instead, the "cylinder" field in the output of this ioctl has been declared obsolete, and is not used anymore. Programs that want to print some value, just because they always did and users expect something, now use BLKGETSIZE to get total size and divide by heads*sectors to get a cylinder value.
(But again: this cylinder value is not used anywhere, the computed value is just for the user's eyes.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines
No. 2.2.* handles large drives since 2.2.14.
This looks more like you used the jumper to clip the drive to 32GB. Don't use it and get full capacity.
If your BIOS hangs when it sees such a large drive so that you cannot avoid using the jumper, use setmax in your boot scripts, or use a kernel patch that does the same at kernel boot time.
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Looks like some short int (2 bytes) overflowing. I'll try the ide patches.
The overflow is in certain BIOSes, not in Linux. (You see in the above: 65531 is not an overflow value.)
The number after clipping was actual - 2^16. Was the reason I was thinking the kernel was playing games. After applying IDE patches the idesetmax message showed up :)
Quoted 16 lines
Quoted 2 lines
I had to recompile fdisk as my old suse 6.4 version got the same 2byte-wraparound problem.
In the good old days the
HDIO_GETGEOMioctl would give you the disk geometry. It has a short for cylinders and hence overflows when C gets above 65535. Since geometry is on its way out - indeed, there has not been any such thing for many, many years - it would have been nonsense to introduce new ioctls that report meaningless 32-bit numbers instead of the present meaningless 16-bit number.
So, instead, the "cylinder" field in the output of this ioctl has been declared obsolete, and is not used anymore. Programs that want to print some value, just because they always did and users expect something, now use BLKGETSIZE to get total size and divide by heads*sectors to get a cylinder value.
(But again: this cylinder value is not used anywhere, the computed value is just for the user's eyes.)
all is block adressed indeed.. I need to look at fdisk, because it is doing things wrong.
The other machine's BIOS can handle 64 GB wihout problems, so I can run without clipping in that machine.
Linux sees the correct size, but fdisk still sees 32 GB. Probably a recompile / upgrade.
Quoted 1 line
Andries
Regards,
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/