3 ms·
I agree with the downstream commenter about this still qualifying as a FW bug, but to be more clear: * there's the story I posted about the OCZ V1 drives eatin
by rincebrain 10y ago
I agree with the downstream commenter about this still qualifying as a FW bug, but to be more clear:
* there's the story I posted about the OCZ V1 drives eating paste periodically while behind redundant power.
* there was a fun problem of some OCZ Deneva 2 drives deciding that they would simply drop off the port and not come back without a cold power cycle, behind redundant power (and a related story about the drives being in such a state, and the AHCI init code on the BIOS getting confused and hanging forever, which was what actually necessitated the cold cycle).
* there was the really fun case someone I worked with came up with where they found a way to reproducibly brick a particular family of SSDs using only about a TB of IO on a 480 GB SSD. (And by "brick", I mean "call the manufacturer, it's not coming back.")
* there was the SandForce bug once upon a time which caused the affected SSDs to not show up correctly as disks under Windows when on SATL because the firmware reported an empty "version" field, and while all the other OSes tested were content with this, and Windows when not using SATL was content with this, Windows when using SATL would report the disk as an "Unknown Device" for this.