Add to drivedb: Kingston DC500R / DC500M

[Matthew Eaton]

Request to add Kingston DC500R and DC500M drive families to drivedb.

Model numbers:
KINGSTON SEDC500R480G
KINGSTON SEDC500R960G
KINGSTON SEDC500R1920G
KINGSTON SEDC500R3840G
KINGSTON SEDC500M480G
KINGSTON SEDC500M960G
KINGSTON SEDC500M1920G
KINGSTON SEDC500M3840G

Data sheet:
​https://www.kingston.com/datasheets/DC500R_us.pdf

SMART attributes sheet:
​https://media.kingston.com/support/downloads/MKP_521_Phison_SMART_attribute.pdf

[Matthew Eaton]

Link to SMART attributes sheet specific to DC500 series: ​https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf

[Christian Franke]

r4944, r4945.

[Matthew Eaton]

Thank you! But there are a couple of incorrect attribute names below. The rest look good.

1. 194 should be Temperature
2. 195 should be Power Fail Health

[Matthew Eaton]

FYI, the unknown attributes (167, 169, 172, 181, 182) are covered here:
​https://media.kingston.com/support/pdf/MKP_521-7_SMART-DC500_attribute_hr.pdf

[Christian Franke]

1. 194 should be Temperature
2. 195 should be Power Fail Health

Indeed, a typo in one attribute number invalidated both. Thanks for catching.

FYI, the unknown attributes (167, 169, 172, 181, 182) are covered here:

Will add these also, thanks.

[Christian Franke]

r4947, r4948.

[Christian Franke]

r4947, r4948.

[yhemery]

Hello,

I tried to use the trunk version of drivedb.h on a SEDC500M960G, but it looks like there are two minor issues related to the bad blocks counters :

• On attribute AAh, the byte mask changed on the DC500 :

DC400 :

Raw Value Byte [1~0]: Early bad block count
Raw Value Byte [5~4]: Later bad block count

DC 500 :

Raw Value Byte [3~0]: Early bad block count
Raw Value Byte [5~4]: Later bad block count

Currently, the both use the same mask (z54z10).

• Attribute C4h is unused on the DC400, and used as "Total Later Bad Block Count" on the DC500. On the DC500 I tested, the attribute is incorrectly interpreted as "Reallocated_Event_Count" (Default value for this attribute).

I may create another ticket if you prefer.

[Matthew Eaton]

I'm unsure on the byte mask issue you brought up. Maybe Christian can clarify on that point?

For attribute 196 it does count later bad blocks, but a later bad block triggers a reallocation event as well. So "Reallocated_Event_Count" is not technically incorrect.

[Matthew Eaton]

Now I think I see what you mean regarding byte mask.

I think byte 3~0 is an error in our SMART document and it should be 1~0. I will confirm with our engineering.

[yhemery]

Ok for the byte mask, thanks for checking.

About the attribute 196 : Most of the definitions I found for the "Reallocated_Event_Count" seems to describe it as the number of attempts by the firmware to move data from a defective block to a safer place : It might end up with a different value than the bad block count if the firmware perform more than one reallocation attempt, unless I'm mistaken ?

[Matthew Eaton]

I see what you're saying and that might be true for another drive manufacturer. Unlike NVMe there is no standard set for SMART attributes for SATA.

The way I understand it is the drive internally keeps track of used spare blocks so logically it wouldn't try to reallocate a bad block to a used/bad spare block and then try again.

[Matthew Eaton]

I heard back from our engineering regarding attr 170:

Since bytes 3~2 will be zero anyway, the documentation is still accurate and future-proof.

So I think we are good until a future drive makes use of bytes 3~2.

[yhemery]

Ok, thanks for taking the time to check that.