OCZ Vertex 2 in Thinkpad T61p

[moijk]

I upgraded my macbook pro to a 256GB OCZ Vertex 4, and the thinkpad t61p inherited the 128GB SSD from earlier. Have had no problems with the 128GB OCZ Vertex 2 so the disk works fine. works fine connected by usb to the same machine, but when used inside the machine i get the error 2100.

It is a t61p with 7700 cpu, 4gb ram and the newest middelton bios. the vertex 2 was purchased a couple of years ago so the firmware on that ought to be way newer than the t61p in any case.

I tried clone the disk that was inside the machine so i'm not sure if the disk boots at all. but it doesn't seem to want to boot from anything else with the disk inside.

Any help is highly appriciated.

[Tim82]

Possibly a loose connection is the problem. Have you tried reinsert the SSD to the hard disk drive bay?

If you have an ultrabay slim sata caddy, you can check the SSD can boot from the caddy.

Edit: a little search on the forum indicates that others experienced similar problems with the Vertex 2/T61 combo. I would recommend a firmware upgrade. My Vertex 2 is a brand new unit with the latest fw, and I never experienced any problems using in my T60 (see signature).

[Cigarguy]

Is the SATA mode in BIOS set to AHCI mode? Did you hook it up as the main drive or via the Ultrabay? What OS are you installing?

[moijk]

Is the SATA mode in BIOS set to AHCI mode? Did you hook it up as the main drive or via the Ultrabay? What OS are you installing?

Windows 7, as main drive. I'll try update the firmware on the drive now to see if that helps. I'll slap it in the macbook pro and try. tried to set to ahci and reseated a couple of times without any luck

[moijk]

I upgraded the ocz vertex 2 to the latest firmware - no dice.
tried without bumpers - no dice
tried without case - no dice

gave up, dropping a 500gb disk in to at least have some kind of upgrade applied to it. the 128gb disk goes back into the macbook pro and the new 256gb goes into the mac pro as boot disk since that has a sata 3 driver.

maybe at one point when i find a ssd drive the t61p supports well i'm going to put the 500gb in the ultrabay or something. when the thinkpad reckognized the 500gb hard drive when i tried that without hesitation i have to say all the trial and error with the SSD didn't even give me a different error.

so newest firmware in the drive and newest middelton bios gave no success. Oh well, i'll only use it for whatever requires windows so having an ssd in it was mosty because i want it in all my laptops.

[Cigarguy]

Sounds like a driver/install issue to me. I've got a couple of T61 with SSD and HDD in Ultrabay combo and really like it. No issues whatsoever. Both machines have Sandforce base 22XX SATA III drives. Your Vertex II should work fine.

[Mike__P]

It is an issue with the Vertex 2 - I just had one replaced that was exhibiting the exact behavior you describe. The replacement vertex 2 works fine in a T60p.

[miamicanes]

The short answer: attempting to clone the disk might have put it into "Panic" mode.

The long, detailed, highly-technical answer:

The specific problem is that Sandforce's reference design included an "optional" ultracapacitor that OCZ (naturally) omitted. The catch is, Sandforce keeps its firmware source (literally) under lock and key, and their firmware (that manufacturers can "customize" in ways that mainly come down to "how far are you willing to risk data loss for slightly better benchmark scores" by having Sandforce build it for you with various parameter values) pretty much depends upon the ultracap being there. Apparently, in the early development stages, Sandforce thought they could get away with omitting the ultracap and work around it via software... and they were wrong. The end result is a drive that can get itself into a state where it can't even boot into its own BIOS, and your data is gone forever if it happens.

Wait, it gets worse/more tragic. There's no technical reason WHY the data can't be 99.9% recoverable by someone with the means to go around Windows/Linux and rip the bits off via JTAG... except for one: Sandforce also enforces whole-disk encryption, so ripping the bits directly from the flash and attempting to do offline recovery without knowing the key would be futile. There's no way to disable it, nor is there any way to set the key to a known value. Apparently, Sandforce also was hoping to sell their controller chips to manufacturers of Hollywood-approved media players, so they had to bend over backwards to make it mandatory & tamper-proof, even if that design decision ended up totally fsck'ing the product's real end users.

Now, let's frost the cake: Sandforce ALSO built countermeasures into their firmware to detect "hacking" attempts. If it decides you're a little bit too interested in trying to read parts of the disk it thinks you shouldn't be asking it to read, it can put the drive into "Panic" mode. What does "Panic" mode do? As far as those of us with access to some rather heavy-duty forensic analysis tools can tell, it blows away the encryption key and sets it to 0xffffffffffffffffffffffffffffffff ("-1"), which completely disables the drive in a way that (so far) can be repaired only by Sandforce itself. For "your" protection, of course. When the drive is in "panic" mode, the consumer-accessible bootloader itself is disabled. Before someone writes our experience with panic mode off as "well, you tried to hack the drive", actually, no. We didn't pull out the heavy artillery until AFTER the drives were in panic mode. The two drives we've analyzed both went into panic mode because we dared to run the notorious, evil hacking tool known as (...drumroll...) "dd_rescue". That's right, attempting to systematically read the drive from start to finish, sector by sector, is apparently enough to induce it to commit suicide and brick itself.

So, basically, what you have is a drive that's almost guaranteed to corrupt itself beyond recovery if it loses power during a write operation, and will brick itself if you dare to try and salvage your data instead of doing a factory erase to make it "bad as new" again.

These drives are basically good for one thing: there are controllers that will basically use a SSD as a write-through cache for a real drive. When you write data, it gets saved to both the SSD and real drive. When you read, it comes directly off the SSD. If the SSD smokes itself, it's basically just an inconvenience... erase and re-initialize the SSD, allow the controller to reimage the cached partition back to the SSD, and you're good to go. There was talk about controllers that would go a step further (and I think some Linux projects to hack alternate drivers that did things like cache recent tracks instead of the whole disk, allowing you to cache a much larger real hard drive than the SSD itself, and another that rolled the dice and did writes to the SSD, but replicated changes to the real disk in the background when idle), but commercially, these products were all evolutionary dead ends that basically came about to try and salvage some value out of billions of dollars worth of fundamentally-flawed SSDs that were too valuable to throw away, but too dangerous to ever trust as a primary hard drive with real data.

Oh... and RAID 1/5/10 won't save you. If your drives are all identical, and something happens that causes one to get corrupted, chances are that ALL of them will get corrupted. Or at least, enough to prevent RAID from doing its job.

The GOOD news is that many new drives -- including ALL of Intel's -- ship with ultracapacitors, so the problem won't happen (or at least, would be like getting hit by lightning, instead of like getting rained on in Florida). The BAD news is that ultracapacitors are (relatively) expensive (by "bottom-feeding every-possible-cost cut to the bone" standards), so not ALL new drives have them... and it's almost impossible to know whether any given drive does or doesn't. With some smaller vendors (who just buy the populated circuit boards from someone in China, package and label them, and sell them under their own name), the vendor ITSELF probably doesn't know. Or care... because the boards it bought were $3 cheaper than the boards from some other factory in China, and most customers won't know the difference until they've had the drives for 3-9 months.

In computer history terms, this ranks up there with Pentium motherboards that limped along at half-speed with a single DIMM and/or no cache, HP's infamous CD-R drives that omitted the memory buffer HP's own engineers described as "mandatory" in their angry emails to HP's management that accurately warned that a drive without a buffer would be almost guaranteed to turn at least a quarter of the discs they tried to burn into coasters), and the PCI soundcards from the late 90s that incorporated the repurposed chipset from the Gravis Ultrasound... but had only a single byte of RAM, and shipped with drivers that basically hacked the original Gravis ones in a way that technically "worked", but destroyed your computer's performance (the original design had onboard RAM, and a later design took advantage of PCI's higher speed to get similar results using DMA; the butchered design did nonstop single-byte DMA transfers. They couldn't do Soundblaster-like PIO, because the card had a design flaw (among many) that caused interrupts to malfunction, so all they could rely upon was "transfer a single byte via DMA, then let the DMA controller fire an IRQ when it finished".

Actually, this last example is probably the closest analogy to the OCZ debacle... it's what happens when you have your factory crank out 20 million boards with a last-minute cost-cutting change that hasn't been properly tested, then you turn around and sell them to consumers *anyway*, blame the consumers when the product malfunctions, and do everything you can to pretend it's just a temporary software problem that can be fixed until the warranties have expired & you can walk away from it.

[RealBlackStuff]

Thank you for this valuable and educational post.
Glad to see confirmed that folks should stay away from OCZ like the devil avoids Holy Water!

[farmall]

Great post indeed! MANY thanks for the info.

[ZaZ]

Glad to see confirmed that folks should stay away from OCZ like the devil avoids Holy Water!

Why? You usually can get OCZ drives for less and I've never had an issue with any of the eight or nine OCZ SSDs I've bought, other than the original Core Drive, which stuttered badly, but that was when SSDs were very new.

[ajkula66]

Thank you for this valuable and educational post.
Glad to see confirmed that folks should stay away from OCZ like the devil avoids Holy Water!

Furthermore, that one should stay away from SandForce controllers in any shape and form...

ZaZ wrote:

Why? You usually can get OCZ drives for less and I've never had an issue with any of the eight or nine OCZ SSDs I've bought, other than the original Core Drive, which stuttered badly, but that was when SSDs were very new.

I've never had any problems with OCZ's older Indilinx-based SSDs and would recommend them to folks still running SATA II boards if it were not for two things:

a) They do not properly fit in a ThinkPad caddy - physically - and I've verified this on several of the older Vertex ones.

b) OCZ customer support is absolutely atrocious.


As for the later, SF-based drives...I don't care what name is on the SSD, if it has a SandBox controller, I won't take it for free...

My $0.02 only...