SandForce "SF-22XX" issues and workarounds

[Anvil]

This thread is for the general discussion and possible workarounds for the SF-22xx based SSD's.

There are lot's of suggested workarounds and we've been scratching the surface in the Endrance thread trying to find a way to avoid the dreaded disconnects, freezes and BSODs that some of the SF-2281 based drives have been plagued with.

In my case I've been having problems with the SF-2281 drive used in the Endurance thread.
In general it lasts for somewhere between 25-35 hours and as it's used as a secondary/spare drive it simply disconnects at some random point, there have been total freezes as well but disconnects is the norm.

Up to date I've been using the drive on both AMD SB850, Intel Z68 and X58 based motherboards and none of them have been successful, in the end the drive disconnects.

Still, there are a lot of suggestions and possible workarounds to try and some of them involve
- RAID option ROM's for the Intel chipsets
- Intel RST Kits/drivers
- Enabling/Disabling TRIM
- Power saving



more to come...

[Anvil]

Reserved

[Christopher]

Is the only way to update the option rom to pre-release 11.x via a BIOS or UEFI update injected with the 11 rom?

[Anvil]

Yes, the "bios" needs to be injected with the option rom.

I'm currently compiling a bit of info and links to where one can find modded bios/uefi's and the tools necessary to extract/inject the option roms.

[Christopher]

I'm trying to bone up on the subject, but it's not straightforward. It looks like some mobos are great for this and some aren't.

BTW, shouldn't you have broken the 51hr continuous mark with your Force 3 by now?

I'm avoiding using certain programs as well, as the Mushkin has only dropped out in the past few days while I was using the system, so basically I'm limiting my use of certain programs like CDI, and instead am just using SSDLife for all endurance updates. While it may sound ridiculous, it really seems like the Chronos Deluxe is always on the edge of just giving up and certain programs like RST's application and CrystalDiskInfo might tip the scales to instability. I haven't had a crash while I was away from the system is almost a week (which might be a guarantee that it happens later...).

[Anvil]

It has gone past 54 hours so it is a new record.
More than 20TiB written in one session.
I'm running CPU-Z + RealTemp + CDI and the occational IE9 or Chrome when posting updates.

It is closing on 2x the expected runtime for this rig, not sure what to expect.

[Christopher]

If past history is any indicator, my Chronos D should punch out between now (25hrs) and the ~30hr mark. I do notice that there are some slight pauses in the system, even thought the testing drive is no longer the OS drive. Maybe during one of these short pauses the drive just can't recover. I'm kinda exploring the option that the drive is running fine until a program does something that upsets stability. Given that I'm only ever in front of the system for a couple hours a day, it can't be a coincidence that it's only crashed when I've been using it in the last week, never when I've been away. As the system drive it would crash every 30 hours or so, then as a secondary it was much sooner, usually at some point over night.

To update to the new UEFI for my motherboard I had to downclock the ram to 1067 and swap in an AMD board instead of my nVidia GTX460. It shouldn't effect the Mushkin one way or another, but who knows? I'd believe anything at this point.

[Anvil]

On this particular setup (ASRock Z68) it has been behaving badly but it looks like the current adjustments do work, for some reason.

It is now 58 hours w/o issues

Corsair Force 3 SSD_120GB_1GB-20111007-1056.png

[bluestang]

@Anvil
You might want to check/get in touch with stasio and Lsdmeasap and let them know what you are trying to do and why. They are both GB gurus and extremely generous with their help. I think they might be willing to help you out in being able to mod the BIOS's yourself.

[Ao1]

Up to date I've been using the drive on both AMD SB850, Intel Z68 and X58 based motherboards and none of them have been successful, in the end the drive disconnects.

Anvil have you tried running different brand SFxxx drives on the mobo’s that have experienced problems when using the Corsair drive? SF2xxx drives might use either a reference or propriety board. The NAND type/ manufacturer will also provide a variable, so it would be interesting to see if one SF brand worked and another did not.

Also have you tried running non SF brands on the mobo’s that have experienced problems with SF drives?

[Anvil]

@Anvil
You might want to check/get in touch with stasio and Lsdmeasap and let them know what you are trying to do and why. They are both GB gurus and extremely generous with their help. I think they might be willing to help you out in being able to mod the BIOS's yourself.

Will do although I,ve managed to find option rom modded bioses for all my X58's, that still leaves the Z68's and a P67.

@Ao1

Sure, all system are running with loads of drives including SSD's.

The ASRock Z68 boots off a Vertex 120GB (gen1) and is also hosting the Kingston used in the Endurance test.
The AMD boots off a WD SSD and hosted the Kingston from early June up until the SF drive caused issues, about a week ago. (The AMD acts as a server and hosts 8 HDD's in raid)
There was an issue with the Kingston on the AMD but the issue was not reproducible.

The X58 I used for the short test which resulted in 51 hour runtime for the Force 3 is my main workstation with loads of SSD's, the X58 I have prepared for further tests currently boots off a Corsair Force GT 120GB.

edit:
The second Z68 is the ASUS M4E-Z, it's booting off 2R0 Crucial m4.

--

The Force 3 is still running, it is close to 65 hours and more than 24TiB is written during this session.

[Ao1]

So the builds are stable with other HDD's/ SSD's (?) If the F3 (as an example) is problematic on one particular set up is an V3 (or any other SF2 drive) also problematic on the same system? If you had more than one F3 would they both play up on the same system or would only one of them be a problematic?

[bluestang]

Will do although I,ve managed to find option rom modded bioses for all my X58's, that still leaves the Z68's and a P67.

Which P67 model?

[Christopher]

I was hoping for more out of the new changes, but like clockwork it just can't handle more than about 30hrs. My drive dropped out this morning. Its just a fact of life now. 30hrs is the ceiling, and its going to happen every time.

What I wonder is why only 2/3s of 1% of 2281's have this problem (according to OCZs stats on their drives). Why don't all 2281s disconnect and BSoD if its the fault of the platform? Now with the progress the Force 3 has made, maybe 11 oroms are the way out of this.

Maybe I should just reboot after every 24hr update...

[Anvil]

Which P67 model?

It's the original Asus P8P67 Deluxe (rev 1), I have not exchanged if for the B3 yet.
I'm more interested in getting OROM updated on the Z68's but the P67 would of course be great as well

I was hoping for more out of the new changes, ...

What did you change?
The one and only thing I have changed is that I have disabled all Power savings, nothing else has changed.

The Force 3 is currently at 71.5 hours.

[Anvil]

So the builds are stable with other HDD's/ SSD's (?) If the F3 (as an example) is problematic on one particular set up is an V3 (or any other SF2 drive) also problematic on the same system? If you had more than one F3 would they both play up on the same system or would only one of them be a problematic?

All systems are stable, the X58 that boots on the Force GT is an exception, will know for sure over the weekend, it's currently sitting there waiting for the Force 3 to fail. I won't stop the Endurance test on the F3 until it's either past 100 hours or it disconnects.
So, when that happens the X58 will host 2x SF-2281 drives.

If it doesn't disconnect I might have to consider making the Force GT the boot drive on the ASRock.
(I wasn't expecting the F3 to last this long...)

[Christopher]

What did you change?
The one and only thing I have changed is that I have disabled all Power savings, nothing else has changed.

The Force 3 is currently at 71.5 hours.

I updated to the 2053 UEFI revision for my Intel DP67BG(B3). To do this, I had to remove the nVidia GPU and swap in an AMD, and have to downclock the ram to 1067MHZ. It won't even boot with the ram at 1333 or higher. It has a slightly different OROM, and I was thinking maybe something would help, but it didn't -- still 30hrs. I've changed Windows 7's power scheme to performance from balanced, and next time I reboot I'll try disabling cstates/eist/speedstep/turbo, and possibly anything else with an off switch .

I'll probably just wait until the drive disconnects again, so probably around this time tomorrow.


If the Force 3 refuses to disconnect, just leave it where it is.... just put a glass case around the system, and write "DO NOT TOUCH" in red lipstick...

[sergiu]

Maybe disabling EIST helps indeed. Jumping from one speed to another adds additional stress on voltage regulator (and also power supply) and some components might not like it too much. Or maybe there are also other internal lines that are reduced.

[Anvil]

There looks to be a connection, but why would that lead to issues with the SF-22XX drives while others are more or less unaffected.

I'll be playing with the Power settings, there are plenty of factors/settings that can be reactivated.

I prefer enabling power savings and so this is not something I can live with but lets see how it develops, I wish I had more drives, that way one could try different settings and the process could be done in days in stead of weeks.

Corsair Force 3 SSD_120GB_1GB-20111008-1147.png

[sergiu]

Robustness principle, "Be conservative in what you do, be liberal in what you accept from others" is not respected most probably by Sandforce and this would explain why it works with other drives. I would be curios to find out which party initiates the disconnect: SSD or chipset?
Also, I was thinking, EIST enabled might lead to higher variations in 5V and 12V lines as CPU goes suddenly from a low load to a high one. Do you have an oscilloscope to check the lines and record max variation during a period of a few hours?

[Christopher]

Hmmmm...

I've had two crashes in the past twelve hours since adjusting the power settings in the UEFI. Turning everything off (speedstep, eist, C states, etc.) seemed to make matters worst. I was a little surprised as I thought it would make no difference.

My system, while running ASU, is always at idle. It doesn't spike up (that I know of), it's just always at idle. Now with it running with no C cstates or eist/turbo I get even more instability.

Not sure where to go from here.

[Anvil]

Are you 100% sure you have made all the necessary adjustments?

CPU-Z should show no signs of power saving, VCore and Core speed should not "move" at all.

[Anvil]

...
Do you have an oscilloscope to check the lines and record max variation during a period of a few hours?

Unfortunately, No.

I'll try to get hold of one early next week.

[Christopher]

Yes, I did it right
I verified that it was idling at the max non turbo multi, and performance power profile was set (with the change that drive sleeps: never)

I'll reboot and try again (for some reason, after I flashed back to the 2040 UEFI, the spash screen lasts for about 2/10s of a second.... I actually have to use a jumper to get into the UEFI now... seriously, power on to desktop is like 8 seconds now). Now the UEFI has been changed back to power savings (Cstates/eist/turbo/etc.) but the power plan is still high performance, but the CPU speed changes from 2.49mhz to 3.29mhz frequently (with a default 99.8 base clock, can't adjust it with anything other that whole increments, not tenths like many boards).

[Christopher]

With regards to the oscilloscope, I think it's a good idea. I've got a fairly high quality power supply (A Seasonic 80+ Gold X 650). It has pretty tight voltage regulation, but it's a 650 watt power supply. I'm idling at 3.3GHZ and it's still only pulling 47w from the wall. I'd be surprised if the PSU doesn't have trouble operating at such a low percent of it's rated output. As far as I can tell, at 47w from the wall, 12w is wasted as inefficiency and maybe I should try a smaller capacity PSU... I've heard that some people have swapped PSUs and couldn't get the SF problem to reappear.

EDIT
Maybe dropping power savings allows the PSU to operate in the sweet spot, where regulation is tightest.