Forgot your password?
typodupeerror
Data Storage Hardware

Intel Confirms Data Corruption Bug, Halts New SSDs 137

Posted by ScuttleMonkey
from the solid-state-death dept.
CWmike writes "Intel has confirmed that its new consumer-class X25-M and X18-M solid state-disk drives (SSDs) suffer from data corruption issues and said it has pulled back shipments to resellers. The X25-M (2.5-inch) and X18-M (1.8-inch) SSDs are based on a joint venture with Micron and used that company's 34-nanometer lithography technology. That process allows for a denser, higher capacity product that brings with it a lower price tag than Intel's previous offerings, which were based on 50-nanometer lithography technology. Intel says the data corruption problem occurs only if a user sets up a BIOS password on the 34-nanometer SSD, then disables or changes the password and reboots the computer. When that happens, the SSD becomes inoperable and the data on it is irretrievable. This is not the first time Intel's X25-M and X18-M SSDs have suffered from firmware bugs. The company's first generation of drives suffered from fragmentation issues resulting in performance degradation over time. Intel issued a firmware upgrade as a fix."
This discussion has been archived. No new comments can be posted.

Intel Confirms Data Corruption Bug, Halts New SSDs

Comments Filter:
  • Ugh... summary.... (Score:3, Informative)

    by blahplusplus (757119) on Monday August 03, 2009 @06:07PM (#28933833)

    "The company's first generation of drives suffered from fragmentation issues resulting in performance degradation over time."

    The performance degradation in the Intel X-25 is not because of a "firmware bug". All SSD's will suffer performance degradation whether or not their writing/wear leveling algorithms have been updated via firmware.

  • by ShadowRangerRIT (1301549) on Monday August 03, 2009 @06:26PM (#28933997)
    The X25-M's initial firmware was unusually bad; the degradation was more rapid and more severe than necessary. Thus, they issued a firmware update [slashdot.org]. The results were quite impressive [pcper.com]. It not only reduced the perf degradation, but it seems to have made writes faster across the board.
  • by ShadowRangerRIT (1301549) on Monday August 03, 2009 @06:30PM (#28934027)
    They probably meant a hard disk password. Depending on implementation, this means either disk supported full disk encryption, or a simple firmware interlock that prevents reading through the controller without the password (but could be bypassed with forensic tools that read the disk surface directly).
  • by Krizdo4 (938901) on Monday August 03, 2009 @06:30PM (#28934035) Homepage

    The performance degradation in the Intel X-25 is not because of a "firmware bug".

    Bugs can cause slowdowns, too

    Though it's highly regarded, Intel's X25-M SSD had a firmware bug that adjusted the priorities of random and sequential writes, leading to a major fragmentation problem that dropped throughput dramatically. The issue was originally uncovered by PC Perspective after two months of testing. Those tests showed that write speeds dropped from 80MB/sec. to 30MB/sec. over time, and read speeds dropped from 250MB/sec. to 60MB/sec. for some large block writes.

    https://www.techworld.com.au/article/302571/ssd_performance_--_slowdown_inevitable?pp=3 [techworld.com.au]

    Before firmware update

    the result suggested a write speed of 30 MB/sec.

    http://pcper.com/article.php?aid=691&type=expert&pid=3 [pcper.com]

    After firmware update

    After composing myself, I did the same file copy I had tried earlier. 76 MB/sec.

    http://pcper.com/article.php?aid=691&type=expert&pid=4 [pcper.com]

    Not a firmware bug?

  • by Anonymous Coward on Monday August 03, 2009 @06:33PM (#28934069)

    As a professional FW tester, I can say 1) firmware can be tested easier than the hardware verification the parent is talking about, and 2) Parent is confusing HW verification with firmware verification. Don't confuse HW verification with Firmware, and don't confuse Software testing with hardware verification. They are vastly different than each other, and have their own set of tools and methods (try sitting through a STAR East or STAR West seminar as a FW tester - it is a total waste of time).

    I can (and do) test firmware on buggy hardware all day long - its not an issue.

  • by owlstead (636356) on Monday August 03, 2009 @06:37PM (#28934107)

    Although this bug should have been caught faster it seems that it is possible to update the firmware without any data loss (fortunately I have put it in a laptop, power outages are no problem). I've looked at the Intel site and the flash utility seems to be simply bootable from CD - if this is the last bug I'll be a very happy punter indeed.

    My 80 GB G2 SSD replaced a not too fast laptop drive. I'm now trying Linux, but I'll try Vista as well just for fun - I'll just write my 80 GB to an external drive using Gparted. These drives come highly recommended even if they would slow down to 50% of performance (which, it seems, they don't). I unzipped Eclipse to it and JavaDoc and I could see that the archiver that unzipped the .zip has some performance issues reading the index. It took longer than the unzipping and gunzipping and untarring (the Eclipse gunzipping/untarring took less than 2 seconds - yikes). The only thing faster is the tmpfs in RAM which I used to compile the OpenJDK in on my "workstation". Starting Eclipse takes now less time on my laptop than on my workstation even though it got twice as few cycles.

  • by blahplusplus (757119) on Monday August 03, 2009 @06:48PM (#28934205)

    "Although Intel acknowledged that all of its SSDs will suffer from reduced performance because of significant fragmentation, the type of write levels needed to reproduce PC Perspective's results aren't likely for everyday users, whether they're running Windows and Apple's Mac OS X. Even so, it still released the firmware upgrade to slow fragmentation."

  • by Anonymous Coward on Monday August 03, 2009 @07:00PM (#28934307)
    Conservatively, 40% of Seagate's high-capacity (1TB+) drives have suffered from a firmware bug which bricked the drive. Seagate has promised free data recovery + firmware fix on affected units - not many people know this! So if your SATA or external Seagate has failed recently on boot, you may be able to recover the drive and your data free. Customer support is very sketchy but if you keep trying for the free data recovery you will succeed. http://www.engadget.com/2009/01/19/seagate-offers-fix-free-data-recovery-for-disks-affected-by-fir/2 [engadget.com]
  • by cecom (698048) on Monday August 03, 2009 @07:26PM (#28934487) Homepage Journal

    The X25-M's initial firmware was unusually bad; the degradation was more rapid and more severe than necessary.

    Unusually bad? More severe than necessary? Not really. Even with this supposed degradation, it was ages ahead of any and all competition. What was unusually bad was the complete lack of understanding from all reviewers who did not understand basic principles and the fundamental limitations of flash and yet rushed ahead with their articles. Those poor fools expected that the driver should behave like a regular HDD - they weren't prepared for the unavoidable deterioration in performance.

    I expect they will be similarly surprised when some drives stop working, because Flash has a very limited number of rewrites. Wear leveling improves the situation, but it just postpones the inevitable. For example, if the driver us full to capacity and you start rewriting a single sector at full speed, you will get to the 10000 rewrite limit relatively quickly.

  • by cecom (698048) on Monday August 03, 2009 @08:13PM (#28934917) Homepage Journal

    Don't answer with generalities unless you have really thought about it. Wear-leveling is based on heuristics; since it cannot predict the future it is always possible to construct scenarios which will hit the worst case. And if it is theoretically possible, it will happen.

    Imagine a simple case and go from there. Imagine a flash with 5 blocks total, 4 sectors per block. The logical capacity is 16 sectors; the extra block is over-provisioned for wear leveling, etc. Now, imagine that you have the 4 blocks neatly filled with occupied sectors and the 5-th block is erased.

    What happens if you want to write to a random sector? The sector is written in the erased space in the 5th block and its physical position is updated in the map. If you repeat that operation 3 more times, the 5th block will get filled with 4 used sectors, and each of the other 4 blocks will have one invalid sector on the average. So far so good.

    What happens if you want to rewrite a random sector now, though? Tough luck. You need to erase a whole block, pack all valid sectors in it, and write the modified sector.

    From now on you get one erase per sector write. Not only that, but you get 3 additional writes. That is called write amplification and is unavoidable in the worst case.

    Now, tell me, how will wear leveling have helped this? Wear leveling works well only well there is plenty of free space. And even then it is possible to construct artificial bad scenarios.

  • by couchslug (175151) on Monday August 03, 2009 @08:13PM (#28934923)

    Aircraft (F-16 among others) flight control firmware has been updated by reprogramming UVPROMs for many years.

  • by AllynM (600515) * on Monday August 03, 2009 @09:29PM (#28935419) Journal

    Welcome to 2 weeks ago:

    http://www.pcper.com/comments.php?nid=7544 [pcper.com]

    Allyn Malventano
    Storage Editor, PC Perspective

  • Re:Typical redditor (Score:4, Informative)

    by NP-Incomplete (1566707) on Monday August 03, 2009 @10:09PM (#28935659)
    On a chip, adding 2^256-1 and 1 may not equal 2^256 when:
    1. Your destination register is 256 bits.
    2. Your destination register is in a different clock domain.
    3. Your timing constraints are wrong.
    4. Your power grid cannot support switching 256 registers.

    Functional simulations will only catch #1.

  • by TheRaven64 (641858) on Tuesday August 04, 2009 @08:05AM (#28938969) Journal
    The FDIV bug wasn't fixed in firmware. There was a microcode update that worked around the problem, but it made division painfully slow. Intel's 'fix' was to recall all of the affected chips and provide replacements. It cost the company a lot of money and the story became the introduction to Andy Grove's biography.

"Consistency requires you to be as ignorant today as you were a year ago." -- Bernard Berenson

Working...