Tejun Heo wrote:Petr Vandrovec wrote:I think that "new" one is correct, while old ones are incorrect (unlessYeah, I realized that and asked Enrico about it. :-)diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.cIs that the right ID string? Strange that that one has Hitachi at the
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00", "SB2IC7EP", ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00", "SBDIC7JP", ATA_HORKAGE_NONCQ, },
+ { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
front and the others don't..
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
output, and I think I verified the patch with the reporter. Hmm... Can
anyone verify these module strings?
Could well be that they've started attaching Hitachi to the ID strings now.. In the past it hasn't seemed to have been Hitachi's (and IBM's before that) practice to have it there, but maybe they see the advantage of being able to figure out who made the drive now :-)