35
\$\begingroup\$

I recently purchased a really, really cheap SSD ($25.99), and I popped open the case out of curiosity.

The flash chips have etched bars across the part numbers, something I've never seen before.

enter image description here

Is this a standard way of marking chips as rejects?

Edit: I bought two of them to put in RAID-1, because I don't trust them too much, and the other one has identical markings:

enter image description here

This one uses Micron flash, though the marking is identical.

At this point, I can only think it must be a really, really, really ineffective attempt to hide the flash part numbers?

The micron parts are MT29F128G08CBECBH6-12:C, which is a 16GByte part, so there is 64 GB of raw storage.

The other parts are "Spectek" branded, which is apparently a micron subsidiary I'd never heard of before. They appear to be FBNL95B71KDBABH6-10AL, which are also 16 GByte parts.

Edit:

The first of the drives passed sudo badblocks -b 4096 -c 4096 -s -w /dev/sdm without error, so apparently the capacity is real, and they are good for at least one write.

Edit edit:

Correction: Either badblocks is crashing my el-cheapo USB-sata adapter, or they do have some issues.

Edit edit edit:

Ok, running badblocks on the drive appears to have confused the disk horribly. Here is the SMART report:

durr@mainnas:/media/Storage/badblocks⟫ sudo smartctl /dev/sdm -a
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-79-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     KingDian S200 60GB
Serial Number:    2016022700031
LU WWN Device Id: 0 000000 000000000
Firmware Version: 20150818
User Capacity:    60,022,480,896 bytes [60.0 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Sun Mar 20 19:15:31 2016 PDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x02) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x11) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        No Selective Self-test supported.
SMART capabilities:            (0x0002) Does not save SMART data before
                                        entering power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        (  10) minutes.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0000   100   100   050    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0002   100   100   050    Old_age   Always       -       0
  9 Power_On_Hours          0x0000   100   100   050    Old_age   Offline      -       2
 12 Power_Cycle_Count       0x0000   100   100   050    Old_age   Offline      -       6
160 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       0
161 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       125
162 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       1
163 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       20
164 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       4943
165 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       12
166 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       1
167 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       4
192 Power-Off_Retract_Count 0x0000   100   100   050    Old_age   Offline      -       6
194 Temperature_Celsius     0x0000   100   100   050    Old_age   Offline      -       40
195 Hardware_ECC_Recovered  0x0000   100   100   050    Old_age   Offline      -       0
196 Reallocated_Event_Count 0x0000   100   100   050    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0000   100   100   050    Old_age   Offline      -       6
241 Total_LBAs_Written      0x0000   100   100   050    Old_age   Offline      -       2857
242 Total_LBAs_Read         0x0000   100   100   050    Old_age   Offline      -       72
245 Unknown_Attribute       0x0000   100   100   050    Old_age   Offline      -       9517

Warning! SMART ATA Error Log Structure error: invalid SMART checksum.
SMART Error Log Version: 1
Warning: ATA error count 0 inconsistent with error log pointer 1

ATA Error Count: 0
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 0 occurred at disk power-on lifetime: 21930 hours (913 days + 18 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 03 ff 93 01 00 ce

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  03 00 00 00 00 00 b9 00      00:00:00.288  CFA REQUEST EXTENDED ERROR
  00 00 00 00 00 00 01 00      00:00:00.000  NOP [Abort queued commands]
  00 00 b3 01 18 00 08 00      00:00:00.000  NOP [Abort queued commands]
  00 02 01 00 00 00 00 4c      16:05:33.861  NOP [Reserved subcommand] [OBS-ACS-2]
  03 00 07 00 00 00 ce 00      00:18:34.183  CFA REQUEST EXTENDED ERROR

Error -4 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 f0 d0 3e 44 a0  Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  b0 d0 01 00 4f c2 a0 00      00:00:00.000  SMART READ DATA
  b0 d5 01 01 4f c2 a0 00      00:00:00.000  SMART READ LOG
  b0 d5 01 00 4f c2 a0 00      00:00:00.000  SMART READ LOG
  b0 da 00 00 4f c2 a0 00      00:00:00.000  SMART RETURN STATUS
  b0 d1 01 01 4f c2 a0 00      00:00:00.000  SMART READ ATTRIBUTE THRESHOLDS [OBS-4]

Warning! SMART Self-Test Log Structure error: invalid SMART checksum.
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%         0         -

Selective Self-tests/Logging not supported

At this point, I've had the drive about a week. I have no idea how it's had errors 918 days ago.

Additionally: Error -4. Yeah, I don't think SMART logs are supposed to have negative numbers. Whoops?

At this point, if I re-test the drive with badblocks, the device actually drops out, and then reconnects.

durr@mainnas:/media/Storage/badblocks⟫ dmesg | tail -n 50
[2048975.197941] sd 12:0:0:0: [sdm] Mode Sense: 28 00 00 00
[2048975.198218] sd 12:0:0:0: [sdm] No Caching mode page found
[2048975.198728] sd 12:0:0:0: [sdm] Assuming drive cache: write through
[2048975.200188] sd 12:0:0:0: [sdm] No Caching mode page found
[2048975.200633] sd 12:0:0:0: [sdm] Assuming drive cache: write through
[2048975.214949]  sdm: unknown partition table
[2048975.215831] sd 12:0:0:0: [sdm] No Caching mode page found
[2048975.216456] sd 12:0:0:0: [sdm] Assuming drive cache: write through
[2048975.216915] sd 12:0:0:0: [sdm] Attached SCSI disk
[2049068.016741] usb 3-5: reset high-speed USB device number 16 using xhci_hcd
[2049068.036966] usb 3-5: device firmware changed
[2049068.037001] usb 3-5: USB disconnect, device number 16
[2049068.040592] scsi 12:0:0:0: rejecting I/O to offline device
[2049068.041057] scsi 12:0:0:0: [sdm] killing request
[2049068.041063] scsi 12:0:0:0: [sdm]
[2049068.041064] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[2049068.041065] scsi 12:0:0:0: [sdm] CDB:
[2049068.041066] Read(10): 28 00 00 44 3e d0 00 00 f0 00
[2049068.041070] end_request: I/O error, dev sdm, sector 4472528
[2049068.041520] scsi 12:0:0:0: rejecting I/O to offline device
[2049068.041974] scsi 12:0:0:0: [sdm] killing request
[2049068.042017] scsi 12:0:0:0: [sdm]
[2049068.042018] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[2049068.042018] scsi 12:0:0:0: [sdm] CDB:
[2049068.042019] Read(10): 28 00 00 44 3f c0 00 00 f0 00
[2049068.042022] end_request: I/O error, dev sdm, sector 4472768
[2049068.056652] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801781c3c80
[2049068.056654] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801781c3cc0
[2049068.168511] usb 3-5: new high-speed USB device number 17 using xhci_hcd
[2049068.259417] usb 3-5: New USB device found, idVendor=152d, idProduct=2329
[2049068.259420] usb 3-5: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[2049068.259421] usb 3-5: Product: USB to ATA/ATAPI bridge
[2049068.259422] usb 3-5: Manufacturer: JMicron
[2049068.259423] usb 3-5: SerialNumber: 201602270003
[2049068.291104] usb-storage 3-5:1.0: USB Mass Storage device detected
[2049068.291152] usb-storage 3-5:1.0: Quirks match for vid 152d pid 2329: 8020
[2049068.291179] scsi13 : usb-storage 3-5:1.0
[2049069.322875] scsi 13:0:0:0: Direct-Access     KingDian  S200 60GB       2015 PQ: 0 ANSI: 2 CCS
[2049069.323058] sd 13:0:0:0: Attached scsi generic sg12 type 0
[2049069.384321] sd 13:0:0:0: [sdm] 117231408 512-byte logical blocks: (60.0 GB/55.8 GiB)
[2049069.384601] sd 13:0:0:0: [sdm] Write Protect is off
[2049069.384603] sd 13:0:0:0: [sdm] Mode Sense: 28 00 00 00
[2049069.384868] sd 13:0:0:0: [sdm] No Caching mode page found
[2049069.385353] sd 13:0:0:0: [sdm] Assuming drive cache: write through
[2049069.386764] sd 13:0:0:0: [sdm] No Caching mode page found
[2049069.387311] sd 13:0:0:0: [sdm] Assuming drive cache: write through
[2049069.396568]  sdm: unknown partition table
[2049069.397466] sd 13:0:0:0: [sdm] No Caching mode page found
[2049069.398067] sd 13:0:0:0: [sdm] Assuming drive cache: write through
[2049069.398513] sd 13:0:0:0: [sdm] Attached SCSI disk

Back to Amazon they go, I guess. I think I'll see if I can convince the other to fail as well, before I return them.

Edit edit edit edit:

Yep, second drive just crapped itself when tested in the exact same manner. Whoops?

\$\endgroup\$
14
  • 3
    \$\begingroup\$ That's really interesting -- wouldn't they be able to test the die pre-packaging as not to waste money packaging a die that's broken? I guess if they don't have that setup, perhaps it's marked after packaging + test to mark non-conformance and then escapes into the "grey" market -- curious to see what the answer is. \$\endgroup\$
    – Krunal Desai
    Commented Mar 15, 2016 at 2:17
  • \$\begingroup\$ It's possible that there was an issue during the silk screening process - in that case they would probably be rejected even if the die was perfectly fine. Out of curiosity have you tested the SSD, any bad sectors? \$\endgroup\$
    – Tom Carpenter
    Commented Mar 15, 2016 at 2:29
  • 1
    \$\begingroup\$ @TomCarpenter Looks more like laser markings than silk screened markings. Reminds me of the fake Chinese USB drives that report large available capacity until you try to actually store and recall more than 2G or whatever- the controller chip has been fiddled. \$\endgroup\$
    – Spehro Pefhany
    Commented Mar 15, 2016 at 2:51
  • 5
    \$\begingroup\$ Maybe they do that to discourage harvesting the chips to sell by themselves. \$\endgroup\$
    – tokamak
    Commented Mar 15, 2016 at 3:41
  • 1
    \$\begingroup\$ Given both types of flash are the same manufacturer (or subsidiary of it), then they were likely produced at the same fab plant (and packaged in the same place). So it is entirely possible that they could still be rejects with the same markings even if they are different ICs. In fact the presence of two completely different flash ICs in the same product does seem to suggest a "we'll use whatever we can get our hands on" attitude which certainly doesn't rule out the use of rejects. \$\endgroup\$
    – Tom Carpenter
    Commented Mar 15, 2016 at 4:23

2 Answers 2

Reset to default
22
+100
\$\begingroup\$

I emailed Ted Netz, the NAND flash product manager at SpecTek. Here's what he had to say (with a few minor grammar and formatting fixes):

Hi Adam,

We do mark products this way. It is a type of part we sell that may have a mechanical defect, but often tested electrically good. We sell it as risk product, as is, at a discount and do a 3 bar deface on it so it cannot be returned as an all good device for RMA. The mechanical defect typically will not let it pass our automated scan steps. Typically it fails for coplanarity or could have a missing or smashed ball. Folks are willing to rework the part and are supposed to retest it. However we usually advise customers to restrict these devices to USB apps or lower tier apps only as they may not meet all performance standards. As well, we cannot control the customer rework process so again we will not warranty such a device.

However there is another odd thing on these. The extra characters H16 62 are not part of our marking scheme. We have had folks counterfeit both the Micron mark and/or the SpecTek mark in this fashion to pass off the parts as SpecTek original. The odd thing to me as well is the scribe adjacent to the pin one mark. On the SpecTek marked drive the font is different on 3 of the marks which do not look like typical Micron scribe fonts. Anyhow hope this helps.

Thx -- Ted

So the three bars are a legitimate marking for high-risk no-warranty discount flash with mechanical defects. Customers are supposed to rework and test the chips on their own. However, based on the extra markings it seems like the chips in your drive might be counterfeit. Maybe it's easier to get away with counterfeiting a lower-quality product.

\$\endgroup\$
8
  • 4
    \$\begingroup\$ That's fascinating. Thanks so much for reaching out on this! \$\endgroup\$
    – Connor Wolf
    Commented Mar 21, 2016 at 23:09
  • 2
    \$\begingroup\$ The extra marks may have been added by the third party that reworked and tested the parts. As in, they are their QA codes. They look like they were applied via a different mechanism. \$\endgroup\$
    – John Meacham
    Commented Mar 22, 2016 at 21:42
  • \$\begingroup\$ @JohnMeacham Based on the failure of both drives, I'm skeptical that any testing was done. But I agree that a third party probably added the extra characters. \$\endgroup\$
    – Adam Haun
    Commented Mar 22, 2016 at 22:05
  • 1
    \$\begingroup\$ @AdamHaun - Considering that they appear to have failed in the same manner, I think buggy firmware is more likely then bad flash, but that's just a guess. \$\endgroup\$
    – Connor Wolf
    Commented Mar 23, 2016 at 21:16
  • 1
    \$\begingroup\$ Well, they went back to amazon on monday, so it's a bit late for that. They're $26 on amazon if you want to experiment yourself: amazon.com/gp/product/B00W2XMUSS \$\endgroup\$
    – Connor Wolf
    Commented Mar 23, 2016 at 22:06
-1
\$\begingroup\$

Possibly the chips are good, but there was a fault in the machine that printed the markings on the chips. But they were still sold and used.

I have seen chips in some devices that have the markings removed in some manner to make the IC unidentifiable, which I suspect may be an attempt to prevent copying of the circuit by cheap ripoff manufacturers. (And DIY hobbyists like myself.)

\$\endgroup\$
1
  • 3
    \$\begingroup\$ We discussed the first point in the comments, however it seems unlikely. Firstly they are laser markings as pointed out by the OP and others, and secondly the lines are not aligned with the original markings which suggests it is done post manufacture. The second point has also been mentioned in the comments, but if that is the case then whoever did it did a very bad job. \$\endgroup\$
    – Tom Carpenter
    Commented Mar 21, 2016 at 1:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.