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:
  • by jtownatpunk.net (245670) on Monday August 03, 2009 @06:25PM (#28933987)

    Future? You must be new to computers. I updated the firmware in my very first 80's printer to give it more features. Had to pop out the old chips and put in the new ones. I upgraded the firmware in modems from several different manufacturers (some more than once) to add features and fix bugs. I've updated the firmware (BIOS) on most of my motherboards. I've updated the firmware on optical drives. I've updated the firmware on a scanner. I've updated the firmware on SCSI controllers. I've updated the firmware on hard drives. I've updated the firmware on switches and routers. Hell, I've updated the firmware on keyboards.

    This is hardly a new phenomenon.

  • Feature Not A Bug (Score:5, Insightful)

    by mrbene (1380531) on Monday August 03, 2009 @06:32PM (#28934061)

    Seriously, I'd say this is in the By Design bucket. For the security conscious - set a BIOS password. If the (feds/aliens/wife/others) remove the password, all access to the data is gone.

    Brilliant! Secure!

    Mind you, not being able to change my password once every other day might hinder my current security model.

  • Re:Well.. (Score:3, Insightful)

    by ShadowRangerRIT (1301549) on Monday August 03, 2009 @06:36PM (#28934103)
    Not really. Making an educated guess from the article, it appears that this is implemented as a simple controller lockout, not actual encryption. So swapping the flash memory into another controller (common computer forensics technique) would bypass it. Most people paranoid enough to want a disk password want real encryption, so using Intel's half-measure of a password is likely a very uncommon scenario. The tests are probably very simple; glossing over this case would be an understandable, if not desirable, oversight.
  • by Anonymous Coward on Monday August 03, 2009 @06:38PM (#28934119)

    Yes, they do.

    C doesn't have voltage or current leaks.

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

    For you software developers out there who enjoy free debuggers, you should know that we, hardware designers, also have our own debuggers. Except they are a little bit more expensive (think $500,000+) and can be quite bulky. But they are the only way to really test firmware before taping-out a chip.

    Or, if you designed your FW properly (as a piece of modularized software running with stubs and drivers for testability), you could have tested it before dumping it to a live EPROM. Or are you proposing that this was a real hardware fault, and not a problem with the firmware?

    Sorry, your software is not a unique snowflake. I know you think it's special because it runs in an embedded environment, but if you chose to ignore what software developers have spent the last 60 or 70 years in developing best practices, then you do it at your own peril. Your failure to do things properly is not because your discipline is light years more complicated than ours, it's simply because you think you are too good to learn from us.

  • by Grishnakh (216268) on Monday August 03, 2009 @06:56PM (#28934273)

    Why bother though? If someone breaks in, you'll have to fix or replace your front door, even though the motion-detecting laser robots zapped him. If you just leave your front door unlocked instead, intruders can just walk in, and the laser-wielding robots can zap him, and then automatically dispose of the body for you too. This way, the intruder won't cause any damage.

  • by Movi (1005625) on Monday August 03, 2009 @07:01PM (#28934317)
    Because suddenly your code becomes time-based, eg it matters WHEN x=0 becomes x=1, and what's in between.

    Believe me, this kicks you in the balls really hard. I still remember the frustration on my Altera course, where in simulation everything worked fine, but once flashed onto a FPGA everything went to shit.
  • by JakFrost (139885) on Monday August 03, 2009 @08:33PM (#28935055)

    This really seems like a very unlikely event to happen to trigger the problem on these drives for most users since from my experience personally and professionally I have yet to see anyone actually know about BIOS passwords, much less about setting a password on the drive using the ATA secure drive password feature. I am surprised that this was even caught by anyone unless it was a complete fluke or there actually are people or companies using this type of a feature for security. (I don't doubt it but haven't seen it.)

    I personally own the first generation Intel X25-M 80GB MLC SSD [intel.com] and I have written about it extensively here on this forum. I heard rumors that the new TRIM feature support will only made available to this second generation release of these drives but I'm unsure if that is really true. I'm on the fence right now whether I should sell my G1 drive and upgrade to the G2 because of this feature and also for a little more performance because I am so happy with the performance of this drive and also the current 8820 firmware that solved the fragmentation and slowdown issues.

    If you are one of those folks who is still sitting around not knowing what to do when all of this Solid State Disk news is coming out all over then you are missing the biggest paradigm shift to computing performance since the transfer from floppy disks to hard drives.

    With the upcoming re-release of this newly affordable drive around 2009-08-28 from Intel X25-M G2 80GB MLC SSD at ~$230 USD from Newegg [newegg.com] or ZipZoomFly [zipzoomfly.com] you should definitely dig down deep and save a little money to buy one of these drives and experience the biggest performance and responsiveness improvement to your computer that you could imagine.

    If you need a primer on the SSD revolution check out my previous post regarding the articles to read.

    Required Reading for Solid State Drives (Score 1) [slashdot.org]

  • by Obfuscant (592200) on Monday August 03, 2009 @10:11PM (#28935671)
    ... just like if you're getting segfaults when writing C you're doing something wrong. It doesn't mean that the process is any less deterministic.

    If you are getting segfaults in C you usually ASSUME that the processor you are running on is acting in a deterministic manner and ASSUME the problem is your code.

    The DIFFERENCE is that SOMETIMES the underlying hardware is not acting deterministically because it is a PHYSICAL system that has physical flaws or imperfections. Like leakage currents that are JUST a tiny bit too much, or depend on the state of the neighboring circuit or the temperature.

    In other words, I've written C code that had "segfaults" and it wasn't the fault of the C code, it was memory issues that resulted in problems. And I've written C code that suffered from a buggy compiler, too. I've also written code that "misread" about 1% of the characters typed in at the terminal, and it wasn't the code that was at fault, it was the UART.

    I don't know anything about the source of Intel's problem, but I will say that they can send me ALL of the "defective" SSDs and I'll give them a home where I promise never to set a password on the disk or change it after I do.

  • by magarity (164372) on Monday August 03, 2009 @10:31PM (#28935823)

    What makes Intel a hard disk vendor anyway? Yes, it is still a disk
     
    It's solid state mass storage, where "solid state" = "chips". A disk is a spinning thingy which is completely different. Since Intel designs and make chips (see: "solid state" = "chips"), it is a perfect choice for them to make solid state mass storage devices out of chips.
     
    Have I mentioned the relationship between "solid state" and "chips" and how "solid state" != "spinning thingy"?

  • by magarity (164372) on Tuesday August 04, 2009 @06:13AM (#28938203)

    I'm not even going to put a foot in the flamefest over whether solid state mass storage is cost effective or even reliable - I only ask you don't call some chips that just sit there a spinning disk.
     
    More than 1/4 of Intel's revenue comes from miscellaney chips [intc.com] and motherboards that are not microprocessors. That's a big enough chunk it shouldn't be dismissed as not a core business.
     
    That this bug made it through means someone should be looking for employment and indicates a problem with management and internal processes, not that they shouldn't make the product in the first place.

What this country needs is a dime that will buy a good five-cent bagel.

Working...