SandForce Identifies Firmware Bug Causing BSOD Issue, Fix Available Today
by Anand Lal Shimpi on October 17, 2011 8:20 PM ESTAfter months of end user complaints, SandForce has finally duplicated, verified and provided a fix for the infamous BSOD/disconnect issue that affected SF-2200 based SSDs. The root cause is a bug in the firmware, although specifics are pretty slim. The typically sparse release notes just state a rare condition resulting in a blue screen error has now been addressed. OCZ has been testing the fix in-house for the past three weeks and now believes it is fit for public release. SandForce is simultaneously releasing the firmware to its partners, so if you have non-OCZ drives you should contact your drive manufacturer for an availability update.
The new firmware is version 2.15 for OCZ drives and 3.3.2 for drives that use SF's standard numbering system. It's important to note that the fix here is for the bug that SF discovered and may not solve all pending issues. Given the extremely long discovery and fix time for this issue I still believe the best policy towards SandForce drives is one of caution, at least until we start hearing from users as to whether or not this fix worked (and didn't create any new issues).
Update: OCZ sent along its official statement -
Source: OCZ
Facebook
Twitter
RSS
30 Comments
View All Comments
FunBunny2 - Tuesday, October 18, 2011 - link
Somehow I have the feeling that Intel will be a tad more aggressive with SF.InterClaw - Monday, October 17, 2011 - link
Here's hoping that this will solve it...! *fingers crossed*InterClaw - Tuesday, October 18, 2011 - link
Yeah okay... It took 5 minutes until my first BSOD. :(On 2.13 I would get like 0-2 of the per day. Using an Asus Maximus IV Gene-Z.
ckryan - Monday, October 17, 2011 - link
I've had a repeatable SF2281 bug that I could get every 30 hours like clockwork, or earlier with MSAHCI drivers, but at random between one and eight hours.Initially, I would get a BSoD after thirty hours. I swapped three different motherboards, and used the drive not as a system drive, but as a secondary. That way it doesn't crash the system, the drive just disconnects (but still needs a manual power cycle). Different RST oroms and drivers didn't matter, using MSAHCI with or without the internal-only port hack made no difference. I know many vendors were claiming they didn't have any way to get a repeatable error, to which I say BS. I was able to find a fix for my system after a few weeks, but it didn't have anything to do with the claimed "fixes". The new fix may or may not stop the "problem", but I find it hard to believe that they couldn't find one system like mine out there. OCZ also claimed that the fault lied with Intel, but I believe this is evidence to the contrary. Also, it is claimed that X79 would fix Intel's problem with SF drives -- something I find doubtful as well, at least in my experience, and even more so in light of this magical FW fix.
I like a lot of the people over at OCZ, but blaming the problem on everything BUT the drive was getting old... as was the old saw that it would be a combination of fixes together that would help with stability, such as Intel getting their stuff together, then SF could get a FW patch to work. So I do indeed hope that the fix is real, and that those afflicted can get their drives functioning like the rest of modern drives -- as they should have from the beginning.
KaarlisK - Monday, October 17, 2011 - link
How did you manage to test different RST oroms?ckryan - Tuesday, October 18, 2011 - link
The three motherboards I tested my drive on all had different versions (and different BIOS/UEFI versions have different RST oroms), but you can take the 11.x orom and "inject" it into the BIOS or UEFI with a few tools. If you have a Gigabyte or Asrock board you can look around. It didn't do me any good as the problem is with the drive... all of them.temporalillusion - Tuesday, October 18, 2011 - link
I have a Patriot Wildfire 240GB not an OCZ, but I was having this exact same problem. I was given a beta firmware update to try (they numbered it 3.3.0) and that resolved the issue completely for me, haven't had a single issue since upgrading.But lesson learned about using bleeding edge tech in a machine I rely on for work.
ajdigital - Tuesday, October 18, 2011 - link
ahh... another update!I recently updated to 2.13 from 2.06 with the constant headache of random shutoff and restarts etc that was plagued with the Agility 3 and the rest of the SF 2200 club I guess. What stopped me from upgrading sooner was the not so user friendly updating process since my SSD was my OS drive. Anyway... I have had NO shutdowns or any issues for 5 days straight so far. (I was lucky to keep an up time of 1 day before with no justification that I could pin point it to) and I have also seen my hard drive regain some speed. I am really looking forward to updating to 2.15 asap!
clarkn0va - Tuesday, October 18, 2011 - link
Is this a Windows only problem? I have an Agility 3 that runs mostly Ubuntu, and a Vertex 3 that runs only Windows 7. I've had no issues on either system.A coworker also runs Windows 7 with a Vertex 3 boot drive and gets "no disc" errors occasionally at boot.
Troff - Tuesday, October 18, 2011 - link
Is it just me or do OCZ/SF seem more confident about this one? I sure hope it's for real.