1

I have a PNY "CS1111" 240 GB SSD which I was using in my old laptop. Then suddenly the laptop stopped booting. The drive shows up in the BIOS as a "0.0GB Solid State Drive", when it used to show PNY and the serial number.

Plugging it into my new laptop via SATA-USB adapter, I noticed a few interesting things. The kernel detects the new device, but it refuses to mount it or perform any operations on the block device, stating, "I/O Error". After some Googling, I found this Intel thread which seems to describe my problem: https://community.intel.com/t5/Solid-State-Drives/sandforce-200026BB-0-0GB/td-p/615575

However, I am not using an Intel SSD, so the firmware update doesn't apply. I also tried using PNY's firmware update tool, but it didn't detect my SSD (even when installed internally).

Below is the output of smartctl:

# smartctl -a /dev/sdb
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-54-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SandForce{200026BB}
Serial Number:    1
LU WWN Device Id: 5 00232d 000000001
Firmware Version: 402ABBR0
User Capacity:    32,768 bytes [32.7 KB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Sat Nov 21 22:48:37 2020 EST
SMART support is: Unavailable - device lacks SMART capability.

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

f3probe:

# f3probe /dev/sdb
F3 probe 7.2
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Probe finished, recovering blocks... Done

Bad news: The device `/dev/sdb' is damaged

Device geometry:
             *Usable* size: 0.00 Byte (0 blocks)
            Announced size: 32.00 KB (64 blocks)
                    Module: 32.00 KB (2^15 Bytes)
    Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1us

fdisk:

Disk /dev/sdb: 32 KiB, 32768 bytes, 64 sectors
Disk model: Ext             
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

From what I can tell, the issue may be caused by the "DevSlp" feature of the SSD (https://en.wikipedia.org/wiki/DevSlp). If this is the issue, is there any way to fix this from within Linux? What further steps should I do to try to recover this drive?

The contents on the drive are quite important, so if possible, I'm trying to recover this drive in a non-destructive way.

2
  • Unfortunately, with the device unable to be seen by the Linux kernel or other OS and even recognized correctly, the chances you can recover the data as an end-user are nearly zero. I would suggest looking for a reputable data recovery company with experience with recovering from failed SSD drives. This is a specialized science and could be quite expensive. We had one at work that did something similar, and the data was recovered, but the cost was more than a typical new high-end gaming laptop. Most data recovery companies will give a quote before performing the recovery.
    – acejavelin
    Commented Nov 22, 2020 at 4:19
  • Have you contacted PNY's tech support
    – JW0914
    Commented Feb 21, 2021 at 15:17

1 Answer 1

1

As your drive is recognised as SandForce{200026BB} , this means that your SSD controller is stuck in "panic mode". It is a common issue with SF-2000 controllers.

You can fix this within Linux: you'll need to operate with Fedora, in order to force-flash a new firmare on the SSD's controller. Unfortunately, you will not be able to retain your data. Flashing the controller will inevitably lead to the loss of all your documents.

Before starting a flashing procedure you can always try having the SSD to "cycle", in order to force it out of panic mode. Try to unplug it from its socket, wait 5 minutes, then plug it back in and open the BIOS, leaving it open for 10 minutes. Then shutdown your computer and wait another 5 minutes. This operations might work if the controller got stuck after an improper SATA wake-up command after hybernation. You may try multiple times before giving up, as it is your only chance to recover your SSD without losing data. If you get a successful recognition, quickly backup all your data, as it might be your last chance to do so.

At that point you may want to try to revive your drive, you need to use SandForce's official software do so. You will lose all your data on it, but if you managed to back it up, then it's not a big deal. This guide describes this rather complex procedure in English, in a very good way IMHO.

2
  • You method of removing it, wait 5 minutes, and put it back, works for me. The mSATA Kingston SSD is recognized. And I can copy the files to another backup drive. But after reboot, it is bricked again and becomes Sandforce. I removed it again, wait 5 minutes and it is recognized. I keep on doing this for 10 times already. Do you have idea? It is attached to my Intel NUC
    – daparic
    Commented Jun 28, 2021 at 12:47
  • 1
    I was lucky enough to have the SSD randomly recognised like yourself and could successfully copy all the data. Then I couldn't accept the idea of my SSD dying like this and I have fully revived it by following the tutorial I linked, if you've managed to copy the data out of the drive, I'd advice you to do the same. I have currently restored my data back on the SSD and it's been working for months
    – BiOS
    Commented Jun 28, 2021 at 12:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .