SandForce "SF-22XX" issues and workarounds

[Anvil]

I'm about to shut down the computer where the Force GT is running, it has been online for 4 days, 21 hours and 46 minutes.
(X58)

[Etihtsarom]

Christ. Since when has it become acceptable that we pay massive money for uncomplete unreliable hardware.

[Christopher]

Christ. Since when has it become acceptable that we pay massive money for uncomplete unreliable hardware.

Well, if some asks me what is the best drive to get, I might not recommend a SF2281 -- but most people don't have these problems. I think the numbers of people who experience this problem is larger than what is generally said to be the problematic population (OCZ claims 2/3 of 1 percent...), but not more than 5 percent probably. It's clearly a fault of the drive, and it's difficult to track down what it is about your system the drive doesn't like. I knew this might happen when I got the drive to endurance test, so I can't really say that I'm torn up about it. I've had success getting the drive to act right, but remember, in the endurance test 10,500GB are being written per day to my drive (if it doesn't crash) so that's pretty stressful. If you have anger management issues or need a reliable system... don't use a SF2281. If you need a fast drive and are willing to put up with some possible problems, then you could consider getting one. The Intel 510 and Crucial M4 are still awesome. The new SATA III Samsung drives aren't available in America yet, and Intel's next SATA III is supposed to come out next month, so your non-SandForce 2281 options are not numerous at this point. It's not like the drives are eating your data, they'll just drop out every once in a while.

The SF2281 drives with Toggle NAND are worth the aggravation in my opinion.

[Christopher]

Double post

[FoLmEr]

Oh, great, a dedicated thread; dunno how I missed this Anyway, I'll include my previous post for good measure:

"Having an SF-22xx drive myself, I've been especially interested in this aspect of the thread. I've owned a Force GT 120GB for a bit more than a month now and I've had crashes with the drive disappearing from BIOS two times only. While not much compared to other folks, it's still annoying, and maybe even more annoying knowing I've got a... fragile... piece of hardware with the potential to cause trouble when it feels like doing so.

So, may we have a recap on the SF issue and can you say anything concrete on the matter in terms of causes/workarounds at this time?

Also, I don't mind helping out if you have some specific BIOS settings/workloads/etc to try out if it brings the world closer to solving the infamous SF problem. This is my only PC tho and it's not running 24/7, so I may not have the same resources but I'll do what I can if needed.

What I have observed around the SF bug myself is that it's only happened during an overclock with an OFFSET vcore while running the BOINC client with the specific settings of 100% CPUs used and 60% CPU time. This configuration results in an erratic load on the processor going literally from 0% to 100% and back down to 0% in under a second with the vcore being thrown around like mad. The first time it crashed within 2 hours of this load and the second time it happened within 10 hours of this load. C3/6 states disabled, altho C1E and EIST have been enabled.

At the moment I'm testing the same CPU workload but with a static vcore."

My system specs are:
2600K
Gigabyte GA-Z68X-UD4-B3 (oROM 10.6.0.1091)
8GB Corsair Vengeance C8
Force GT 120GB (FW 1.3.2) as systemdrive restored from an HDD image of Win7 (alignment is ok)
IRST 10.6.0.1002

I should mention that I haven't experimented with any voodoo like reg hacks, modded BIOSes, uninstalling/disabling MEI or even MS default SATA driver. I've pretty much only updated FW of my drive after the second crash and haven't had any crashes since, but I also have not tried provoking it with the conditions I mentioned earlier.

[Christopher]

Oh, great, a dedicated thread; dunno how I missed this Anyway, I'll include my previous post for good measure:

"Having an SF-22xx drive myself, I've been especially interested in this aspect of the thread. I've owned a Force GT 120GB for a bit more than a month now and I've had crashes with the drive disappearing from BIOS two times only. While not much compared to other folks, it's still annoying, and maybe even more annoying knowing I've got a... fragile... piece of hardware with the potential to cause trouble when it feels like doing so.

So, may we have a recap on the SF issue and can you say anything concrete on the matter in terms of causes/workarounds at this time?

Also, I don't mind helping out if you have some specific BIOS settings/workloads/etc to try out if it brings the world closer to solving the infamous SF problem. This is my only PC tho and it's not running 24/7, so I may not have the same resources but I'll do what I can if needed.

What I have observed around the SF bug myself is that it's only happened during an overclock with an OFFSET vcore while running the BOINC client with the specific settings of 100% CPUs used and 60% CPU time. This configuration results in an erratic load on the processor going literally from 0% to 100% and back down to 0% in under a second with the vcore being thrown around like mad. The first time it crashed within 2 hours of this load and the second time it happened within 10 hours of this load. C3/6 states disabled, altho C1E and EIST have been enabled.

At the moment I'm testing the same CPU workload but with a static vcore."

My system specs are:
2600K
Gigabyte GA-Z68X-UD4-B3 (oROM 10.6.0.1091)
8GB Corsair Vengeance C8
Force GT 120GB (FW 1.3.2) as systemdrive restored from an HDD image of Win7 (alignment is ok)
IRST 10.6.0.1002

I should mention that I haven't experimented with any voodoo like reg hacks, modded BIOSes, uninstalling/disabling MEI or even MS default SATA driver. I've pretty much only updated FW of my drive after the second crash and haven't had any crashes since, but I also have not tried provoking it with the conditions I mentioned earlier.

See, this sounds like system instability, not the GT exhibiting the SF behavior. Why are you so sure that it is the Force GT doing this, and not your system?

The best way to test this out is to use another drive as the system drive and the Force GT as a secondary drive. This way you can isolate the issue, as my Mushkin Chronos Deluxe as the system drive would crash the whole system when it became unstable. As a secondary drive, the drive just disconnects and your system will still do whatever -- unless it's your motherboard not keeping up Vcore, in which case it's not the drive.

[FoLmEr]

See, this sounds like system instability, not the GT exhibiting the SF behavior. Why are you so sure that it is the Force GT doing this, and not your system?

The best way to test this out is to use another drive as the system drive and the Force GT as a secondary drive. This way you can isolate the issue, as my Mushkin Chronos Deluxe as the system drive would crash the whole system when it became unstable. As a secondary drive, the drive just disconnects and your system will still do whatever -- unless it's your motherboard not keeping up Vcore, in which case it's not the drive.

I assumed it was the disk as I had the SF behavior people describe just prior to the crash: one ~30 sec freeze followed by an X second period of applications stop functioning one by one followed again by the F4 BSOD. That is, as I see it, the disk disconnecting prematurely. It really leaves little doubt as to what's happening if you ask me.

The other time it happened, I just had like a frozen 640x480 rectangle sliced out from the middle of my desktop with the mouse cursor being double the size of normal. I had a black background at that time so if I hadn't had the cursor shown, I'd just have thought it was a black screen. It points me in the direction of the graphics driver breaking due to the disconnect and then it didn't even make it to the BSOD, but simply froze. I've seen people report this as well on the SF issue. Disk didn't show up in BIOS afterwards. I haven't had that disk disappearing behavior on failed OCs ending in BSOD.

Also, the system running overclocked had been stable for 4 weeks until I started playing with offset vcore, whereafter I see the SF disappearing behavior.

I'm not knowledgeable in this area, but could the erratic load/vcore disturb the SATA signal, making the SF crap out? Also, I hadn't disabled LPM at that time, could that play a part too?

[FoLmEr]

double post

[Christopher]

Well, some have found that disabling the power saving features help stability. Then there are another class of SF2281 issues that I've experienced that are caused from Anvil Storage Utilities it seems, as during file deletion more of a pause is needed or the drive disconnects. That's probably not what's happening in your case as this is most likely limited to endurance testing. I found that ASUs pause wasn't long enough until I was generating more than 10000 files per loop. So that's another issue.

I know from experience that if you drop the System Agent and/or PCH voltage low enough that you'll get crashes. This is total speculation, but you could try increasing those a few notches in your BIOS.

[FoLmEr]

Yeah I'm not so fortunate as to have a mainboard where the MCH voltage is actually adjustable I'm afraid. It totally shocked me when this turned up as a possible solution and I have no idea why Gigabyte didn't include this in their BIOS.

I might play around with the System Agent voltage, but for now I haven't established if it's the 1.3.2 FW or static vcore that keeps the drive running (it HAS crashed with c3/6 states disabled).

Just waiting anxiously for the next crash... :S

[kensiko]

Kensiko,

Are you having problems with a SF2281?

If so, could you list the full system specs of the system that's experiencing the problems?
I'm just curious, and it might be handy to have some people here with the problem in the future.

Or were you just wondering what the hell I was doing? Because sometimes I wonder that myself...

Sorry to answer late. No I don't have any SF2281 yet, but I'm going to have one this week. I'm mainly interested for helping people in the OCZ forum and maybe for our server at work, currently running with SF12xx but we are planning to buy another SSD and the SATA 6Gbps may be preferred by the IT guy who ask me for recommendations. Not sure what I will answer yet. But in Canada the OCZ SSD are clearly more competitive in term of price.

[Christopher]

My Mushkin will crash regardless of motherboard. I've tried swapping in an Biostar TH67+ H67 and an Asus Maximus IV Gene-z Z68 in place of my Intel DP67BG, and it crashes regardless. Using MSAHCI drivers makes it happen at random (and quickly), but the Intel RST drivers gave me more stability.

[Christopher]

Sorry to answer late. No I don't have any SF2281 yet, but I'm going to have one this week. I'm mainly interested for helping people in the OCZ forum and maybe for our server at work, currently running with SF12xx but we are planning to buy another SSD and the SATA 6Gbps may be preferred by the IT guy who ask me for recommendations. Not sure what I will answer yet. But in Canada the OCZ SSD are clearly more competitive in term of price.

The drives with Toggle NAND are the best in my opinion. The Patriot Wildfire, Mushkin Chronos Deluxe, OWC Mercury Extreme Pro 6G, and that small company that no one has ever heard of... what's the name... oh yeah, OCZ has the MaxIOPS.

They're all around the same price as one another, but every once in a while you can find some good deals on the WildFire and Chronos DX, and sometimes the MaxIOPS. If you're going to get a SF2281, then one of those are what you want. Otherwise, just get a Crucial M4 or something.

[kensiko]

Guys, firmware 2.15 just came out for OCZ, it will probably get for the others soon too.


Changes:

Fixed a rare condition that may cause Windows Blue Screen error when the primary-configured drive woke up from either a SATA slumber mode or S3/S4 modes
Fixed a rare condition that may cause Windows Blue Screen error when the drive was configured as primary with OS installed
Fixed a corner-case issue that may cause the drive to stutter or Windows freezing screen when a media read error occurred
Further improved robustness of Secure Erase operation to prevent possible low-level data structure corruption
Significantly improved TRIM handling to enhance system stability

Vertex 3 series, Vertex 3 Max IOPS series, Agility 3 series, Solid 3 series Known open issue:

Formatting a RAID1 volume takes longer than expected with PMC-Sierra BR-8 HBA

[squick3n]

http://www.anandtech.com/show/4973/s...vailable-today

Supposed to be going out to all vendors. Hopefully they've cleared it up. Just in time for Intel's new SSD

[Christopher]

http://www.anandtech.com/show/4973/s...vailable-today

Supposed to be going out to all vendors. Hopefully they've cleared it up. Just in time for Intel's new SSD

Yeah I just posted that on the endurance thread.

These people are probably just using ASU to figure out what to fix... If they needed two systems with easily replicated issues, there are two right here.

They should beg me to test their stupid firmware for them...

[Anvil]

I'm not able to get my Corsairs to disconnect nor BSOD anymore, all settings are back to normal on the Z68.
So I was beginning to wonder what changed, I'm now almost confident that it's the firmware that made most of the difference.
Orom did not seem to matter at all, the one thing that looked to make sense was power related settings.

The question is, does Corsair fw 1.3.2 = SF fw 3.3.2, did they make an early release or is there something more?

Some if my Vertex 3's are still on 2.02 and some are 2.06/2.09/2.13, no issues but it looks like it's time to get all on the same fw.

[Computurd]

I agree.

Also, i don't believe that SF isolated this problem, i think they had help. There is a certain someone who is most interested in SF lately...regardless if this is what it looks to be, hallelujah!

[Anvil]

Let's hope that *this* is it!
The new SF controller really is good but I can see that some are reluctant and stay away.

The 240GB drives have never caused BSOD's or disconnects for me and that covers both the Intel PCH and the LSI 926X controllers.
I find that strange as all other capacities have caused issues for me at some point, well, maybe I was just lucky?

[Christopher]

If you're not having problems anymore, then perhaps you should just stick with what you have... who knows as to what fresh new disorder a FW update could bring to a drive that works?

[Anvil]

One can always return to an earlier firmware

My confidence is pretty good on the 1.3.2 (Corsair) and so I don't think I'm taking any chances in upgrading the OCZ's.
In the end there's always the sneaking suspicion that something is wrong and so I'm prepared to spend some time verifying that it's stable.

[Christopher]

I've got a good thing going on for testing FW here, so if there are any weaknesses... it should pop up. Seriously, you should try dropping the Min free space down on the Force 3 to see if it still crashes under TRIM like the Mushkin.

And I swear that the only way to get a consistent SF fault is to use ASU for endurance testing. Dollars to doughnuts, that's what SandForce had to do to find this magical system.

[FoLmEr]

@Anvil
Are you going for the new firmware when it becomes available for your GT even if the drive has proven stable with 1.3.2 as you suggest is has?

[Anvil]

Yes,
I'll definitely be upgrading both Corsair's as soon as the new firmware is available, will most likely do the GT first.

[Ao1]

I had a weird experience with my V3 after updating to the new firmware. (Previously the drive has been faultless). Check out the MB/s. With uncompressible writes ASU is normally around 57MB/s. I was getting up to 76MB/s and then bam, for a good 60 seconds ASU became unresponsive and write speeds dropped. Write speeds then went back to 57MB/s. I suspect that a major housekeeping clear up event occurred (GC/ TRIM) mid-way through the loop as I’d been playing with 4K random writes before I started ASU. I'll see if I can reproduce it later.