I have set this oldish BIOS to "auto". These are CHS values reported
by default, using kernel 2.2.9 and hdparm 3.5:
kernel 1027/255/63
(kernel 2.0.36 1024/255/63)
hdparm -I (raw)
CurCHS 16383/16/63
LBA CHS 1023/256/63
CurSects 16514064
LBAsects 16514064
hdparm -i (cooked)
CurCHS 1027/255/63
LBA CHS 513/510/63
CurSects 16514064
LBAsects 16514064
1024*255*63 = 16450560
513*510*63 = 16482690
1027*255*63 = 16498755
1023*256*63 = 16498944
16383*16*63 = 16514064
It would _seem_ that all the dividing down that hdparm does is a bit
bogus when applied to odd numbers, as it results in the loss of the
end of the disk.
The drives work fine when forced to 16383,16,63. This is also the CHS
given by IBM in the datasheet (though they say, "as reported by the
XYZ command") and the number of sectors also matches that. Going for
16384*16*63 gives seek errors, so that's too big.
Thanks for any reply,
Giuliano Procida.
-
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/