Hello.
Mark Lord wrote:
Hanno Böck reported a problem where an old Conner CP30254 240MB hard
drive
was reported as 1.1TB in capacity by libata:
http://lkml.org/lkml/2009/2/13/134
This was caused by libata trusting the drive's reported current
capacity in sectors in identify words 57 and 58 if the drive does not
support LBA and the
current CHS translation values appear valid. Unfortunately it seems
older
ATA specs were vague about what this field should contain and a
number of drives
used values with wrong byte order or that were totally bogus. There's no
unique information that it conveys and so we can just calculate the
number
of sectors from the reported current CHS values.
Signed-off-by: Robert Hancock <hancockrwd@xxxxxxxxx>
..
} else {
if (ata_id_current_chs_valid(id))
- return ata_id_u32(id, 57);
+ return id[54] * id[55] * id[56];
else
return id[1] * id[3] * id[6];
..
NAK. That's not quite correct, either.
The LBA capacity can be larger than the CHS capacity,
so we have to use the reported LBA values if at all possible.
That's why ata_id_is_lba_capacity_ok() exists,
and why it looks so peculiar.
I think that checking LBA validity is a matter of another patch. This
patch in itself should be sufficient.
Some of those early drives really did require that kind of logic.
I hightly doubt that this 240 MB drive is LBA capable at all.
Cheers
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
