P3-128, HDD LED stays lit, bad clusters

Here's some background:

 

1. I turn on the PC, waking it from hibernation (I don't use the hybrid hibernation, by the way).

2. Windows 7 starts fine.

3. After a couple of minutes of normal use (browsing), the system froze, forcing me to turn off the computer by holding down the power button.

 

Windows 7 never gets past the Starting Windows screen, and the HDD LED stays lit solid.

 

 

 

The issue/symptoms:

The HDD activity LED stays lit solid, Windows can't boot. In safe mode, from a local start of PE recovery (from the P3), it reaches CLASSPNP.SYS, IIRC.

 

Things I have tried:

* I have disconnected all other drives, to boot the P3 alone.

* I have tried booting from the Windows 7 media, but it hangs when it assumedly attempts to access the drive.

* Booting W7 media without the SSD is fine.

 

 

I then used a spare SATA HDD to install Windows 7, then use a SATA/USB Bridge to connect the P3. Results so far:

 

 

Log Name: System

Source: Ntfs

Event ID: 55

Task Category: (2)

Level: Error

Keywords: Classic

User: N/A

Description:

The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume F:.

 

Disk Management reports the file system as raw.

 

 

Here's a recap:

C: The SATA HDD I use currently.

D: The optical drive

E: The P3-128 drive, Windows 7 reserved partition appears immediately.

F: The P3-128 drive "C": The drive did not appear immediately.

 

 

I start a cmd shell, run chkdsk f: /f, and it reports two bad clusters.

 

The type of the file system is NTFS.

Volume label is Irrelevant.

 

CHKDSK is verifying files (stage 1 of 3)...

219392 file records processed.

File verification completed.

324 large file records processed.

0 bad file records processed.

2 EA records processed.

60 reparse records processed.

CHKDSK is verifying indexes (stage 2 of 3)...

286542 index entries processed.

Index verification completed.

0 unindexed files scanned.

0 unindexed files recovered.

CHKDSK is verifying security descriptors (stage 3 of 3)...

219392 file SDs/SIDs processed.

Security descriptor verification completed.

33576 data files processed.

CHKDSK is verifying Usn Journal...

Repairing Usn Journal $J data stream.

Usn Journal verification completed.

Adding 2 bad clusters to the Bad Clusters File.CHKDSK discovered free space marked as allocated in the

master file table (MFT) bitmap.

CHKDSK discovered free space marked as allocated in the volume bitmap.

Windows has made corrections to the file system.

 

124930047 KB total disk space.

75985672 KB in 179092 files.

104312 KB in 33577 indexes.

8 KB in bad sectors.

290023 KB in use by the system.

65536 KB occupied by the log file.

48550032 KB available on disk.

 

4096 bytes in each allocation unit.

31232511 total allocation units on disk.

12137508 allocation units available on disk.

 

When I ran chkdsk F: /f, it would slow down considerably at around 60-70 %.

 

After that, I could access the drive, as in seeing a list of files and folders. I haven't tried accessing further.

 

I currently have chkdsk with /r running, to see if it could detect any more problems before I'd try booting the SSD again.

This does take time. It has stayed at 17 % for the last couple of hours, correcting errors of the sort: "Windows replaced bad clusters in file N"

 

 

I guess I should have it replaced? But I'd like to know more, in case there are known issues with this SSD. Thanks.

 

That said, I also have an X25 from Intel, which has experienced the same usage pattern; hibernate, and the occasional power-off due to the reality of software.

 

**

 

chkdsk /r has completed

 

219376 files processed.

File data verification completed.

CHKDSK is verifying free space (stage 5 of 5)...

12136817 free clusters processed.

Free space verification is complete.

Adding 561 bad clusters to the Bad Clusters File.

Correcting errors in the master file table's (MFT) BITMAP attribute.

Correcting errors in the Volume Bitmap.

Correcting errors in the Volume Bitmap.

Windows has made corrections to the file system.

 

124930047 KB total disk space.

75985680 KB in 179093 files.

104312 KB in 33578 indexes.

2252 KB in bad sectors.

290535 KB in use by the system.

65536 KB occupied by the log file.

48547268 KB available on disk.

 

4096 bytes in each allocation unit.

31232511 total allocation units on disk.

12136817 allocation units available on disk.

Secure erase the SSD and try a clean install of the OS or restore from a known good image if you have one. Clean install is best.

 

Also, if you have had another completely different SSD do the same thing, you may have some issue with your drive controller.

Tried to boot from the drive just now.

Same symptoms as before.

Just right after the windows 7 screen (still black colored).

 

Secure erase the SSD and try a clean install of the OS or restore from a known good image if you have one. Clean install is best.

Do Corsair have tools for this?

OK, I'm reading this for now: http://blog.corsair.com/?p=4484

 

Also, if you have had another completely different SSD do the same thing, you may have some issue with your drive controller.

No, just this P3 drive so far.

They are both connected to the same controller.

 

 

I have a hard time attributing this to software error, though.

 

 

Also: The cables are the ones either supplied by ASUS or Corsair, since it was intended for 6Gb/s. They have a clip to secure them. In any case, the SATA protocol does error checking, ie signals whether a resend is needed, so data corruption shouldn't occur, IMHO.

Having read the document, How To Parted Magic, I don't see how filling a drive with zeroes could solve this. Are we talking about internal errors in the bits stored on the drive, which are inaccessible through normal file system operations? In that case, is it an error in the firmware? Is there an update?

The security erase command cannot be performed.

 

 

I have now tried disk erase using parted magic, both in IDE and AHCI mode.

 

It can't proceed, because it claims the SSD security state is frozen.

 

The disk erase program suggested to put the system in sleep mode, and then resume, to have it reset the frozen state.

 

I also tried a shutdown, turning off the PSU.

The security erase command cannot be performed.

 

 

I have now tried disk erase using parted magic, both in IDE and AHCI mode.

 

It can't proceed, because it claims the SSD security state is frozen.

 

The disk erase program suggested to put the system in sleep mode, and then resume, to have it reset the frozen state.

 

I also tried a shutdown, turning off the PSU.

 

Hot swap the drive after you get the frozen message. Unplug it for about 30 seconds, then reapply power to it.

I contacted the reseller and explained this problem as described here. They had me request an RMA. They were not aware of the secure erase method.

 

 

Apparently, doing a hot plug might force the system to crash due to the sudden voltage drop, if the SATA drive is on the same power cable as the OS.

You are ultimately going to find out that your problem is your P67/Sandy Bridge combination. Microcode in the Intel Sandy Bridge CPU has problems with most of ASUS P67 motherboards and Sleep/Hibernate.

 

Go into your BIOS (UEFI), and turn "off" (Disable) the setting for PLL Overvoltage. If you are overclocking, you will find that you have to make a choice... Sleep/hibernation with the setting disabled, or OC with it on... Unfortunately, you can't have both.

 

With PLL Overvoltage turned "on", coming out of sleep/hibernationand a CPU multiplyer higher than the stock 3.4, the CPU/Motherboard does not re-power up correctly, and the system freezes. Unfortunately, even the turbo-boost setting of 3.8 can cause the problem. The problem is also sporatic (not everyone has the problem). Make sur your Sabertooths BIOS (UEFI) is up to date.

 

You will also find that sometimes it will BSOD if the system can catch the freeze up before it happens, otherwise, a BSOD can't even be generated because of the hang.

I contacted the reseller and explained this problem as described here. They had me request an RMA. They were not aware of the secure erase method.

 

 

Apparently, doing a hot plug might force the system to crash due to the sudden voltage drop, if the SATA drive is on the same power cable as the OS.

 

It won't hurt anything to try it. I do it all on the time on 2 different ASUS Sandy Bridge boards without issue. That ASUS link lays the blame on PSUs. Try it as I described and if you have issues let us know.

To the OP, this is a documented issue with this series of drives (Performance Series 3). While they sell far less of these than their Force series, these have just as many issues honestly.

 

I have a P55 chipset from the previous generation Core i series and I had the exact same issue, as do many others.

 

Just search this forum, you'll see a bunch of posts about the same issue.

 

 

There is NO known fix other than replacement just to have it happen again.

While they sell far less of these than their Force series, these have just as many issues honestly.

 

No, they do not. If you are using the Marvell controller, keep in mind that those controllers are bugged and have a variety of issues all their own that are independent of the drive.

As I understand the claims,the Marvell Controller may corrupt the contents of an SSD drive, and a secure erase would solve this? (The P3 was connected to the Marvell, along with the other SSD. The P3 was more prone to writes, being a system disk.)

 

 

Anyway, they tested the drive, confirmed the described problem, thus acknowledged the RMA request.

 

 

I will use the 6 Gb/s ports on the Intel controller this time. I don't have any real evidence for laying the blame on the Marvell Controller, but it won't cost me anything to try the Intel controller. This is not very scientific, and I don't have the resources of Microsoft's WHQL (which did pass the Marvell driver).

 

 

ASUS have no newer drivers for the Marvell Controller.

I have the latest (non-beta) BIOS.

 

 

Although I went for an OC-friendly CPU (*K), my intention was not to overlock the system, but to get a stripped down version of the CPU (no vPro etc).

 

I will look into the tips. Thanks!