Re: 2.2.18 and Maxtor 96147H6 (61 GB)

[Igmar Palsenberg]

> 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.
> 
> >> 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 :) 

> > 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.)

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.
 
> Andries

	Regards,

		Igmar