Re: [PATCH v2] libata: Don't trust current capacity values in identify words 57-58
- From: Robert Hancock <hancockrwd@xxxxxxxxx>
- Date: Mon, 02 Mar 2009 18:53:14 -0600
Robert Han*** 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.
While we're at it, clean up this function to use named constants for the
identify word values.
Signed-off-by: Robert Hancock <hancockrwd@xxxxxxxxx>
Jeff, any thoughts on this one? I would suggest it's -upstream material (for .30)..
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 9fbf059..33b5549 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1322,14 +1322,16 @@ static u64 ata_id_n_sectors(const u16 *id)
{
if (ata_id_has_lba(id)) {
if (ata_id_has_lba48(id))
- return ata_id_u64(id, 100);
+ return ata_id_u64(id, ATA_ID_LBA_CAPACITY_2);
else
- return ata_id_u32(id, 60);
+ return ata_id_u32(id, ATA_ID_LBA_CAPACITY);
} else {
if (ata_id_current_chs_valid(id))
- return ata_id_u32(id, 57);
+ return id[ATA_ID_CUR_CYLS] * id[ATA_ID_CUR_HEADS] *
+ id[ATA_ID_CUR_SECTORS];
else
- return id[1] * id[3] * id[6];
+ return id[ATA_ID_CYLS] * id[ATA_ID_HEADS] *
+ id[ATA_ID_SECTORS];
}
}
--
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Prev by Date: Re: lockdep and threaded IRQs (was: ...)
- Next by Date: Re: [PATCH 0/4] cgroups: show correct file mode
- Previous by thread: [2nd REPOST] [PATCH] ARM: MMU: add a Non-cacheable Normal executable memory type
- Next by thread: Large amount of scsi-sgpool objects
- Index(es):