HDD Firmware: To Patch or Not To Patch?

[nweissma]

consider this samsung HD204UI hdd:
http://www.newegg.com/Product/Produc...20110603072217 }

there appears to be a serious firmware problem with it based on the one-egg ratings. samsung acknowledges this and provides this firmware patch:
http://www.samsung.com/global/busine...bbs_msg_id=386


i understand that Samsung fixed the firmware issue on those HD204UI's that were manufactured on or after Dec. 2010, that these have serial number xxxxxxZCxxxx, and that HD204UI 's that were manufactured prior to Dec. 2010 -- and they therefore need the firmware patch -- have the serial numbers xxxxxxxZ7xxxxx, xxxxxxxZ8xxxxx, xxxxxxxZ9xxxxx, xxxxxxxZAxxxxx, or xxxxxxxZBxxxxx. is this correct -- the information was obtained from unreliable sources (newegg posts)?

** what will be the consequences of applying this firmware patch to an HD204UI that does not need it? ** can this cause irreversible damage? how do i recover from it?

this post is related http://forums.anandtech.com/showthread.php?t=2153493&highlight=hd204ui

i have entreatied samsung cs at least 4 times -- their hdd section ("our hard drive specialist will contact you") is as useful as a rubber crutch.

update: i purchased the HD204UI on June 24, from newegg, with apparent mfg. date April 2011 and a serial number that does resemble any of the aforementioned paradigms. if that means anything. i will not invoke Samsung's F4EG firmware patch.

 

[Emulex]

its not uncommon to slow things down a little to lower the return rate. tweak timings to be a little looser. i'd suspect the firmware won't apply to drives not applicable.

 

[code65536]

I have this exact Samsung drive (and I flashed it because I got it right as the problem was discovered). The word from Samsung, by way of their support department is that it should be fine starting in the December drives. But to be safe, I would strongly recommend flashing January drives as well.

The best source of information about this problem is at the following wiki:
http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks

I don't expect there to be any downside to flashing the drive if it does not need it. Samsung did not increment the version number, so you don't know if you have the old or new. But there shouldn't be any problems if you flash it unnecessarily (unless something goes wrong with the flash itself, which is always a possibility).

Finally, the wiki contains technical details regarding the nature of the problem (in NCQ mode, issuing an identification command causes the drive to lose the write commands already in the queue, so this is purely an "administrative" issue) and ways to reliably reproduce the problem (so you can check if the drive is affected or not).

If you do need to flash, there is a good guide here about how to do so:
http://code.kliu.org/.etc/samsung_f4eg_flash/

 

[nweissma]

do you have any thoughts about whether i can successfully flash the firmware while the HD204UI is in a usb 2.0 external enclosure http://www.newegg.com/Product/Produc...-042-_-Product

or is integration into the tower sine qua non?

call me chicken little but i am seriously worried about whether samsung's firmware patch might wreak havoc on an archival samsung 1tb hdd that is now integrated into the tower -- i really hate surprises and a surprsie of this magnitude will push me into a homicidal frenzy (a similar case a few years ago with an ubuntu install on D tsunamied both D and Vista C). i know that i can simply physically disconnect the archival samsung but i am academically curious about your thoughts.

 

[corkyg]

Unless you sense some problem with the drive, why flash it? My personal rule is always - if it ain't broke, don't fix it.

 

[RaiderJ]

I have six of those drives, flashed them all before use. Haven't seen any issues, but I didn't do any tests before and after. The nature of the patch is a bug fix, I can't see why you wouldn't want to patch.

 

[bryanl]

Unless you sense some problem with the drive, why flash it? My personal rule is always - if it ain't broke, don't fix it.

That's good advice, and I wish I had followed it before flashing my Hitachi HDD to fix a problem that affected only some benchmarks but never any real life applications. The HDD used to be silent but now makes annoying sounds during every seek, and just my luck, I can't adjust it through AAM or flash back to the original firmware.

 

[code65536]

I tried flashing the drive in an enclosure, and it did not work. But I don't know if that's because of the particular enclosure that I was using, so YMMV.

The flasher is not dumb and it should skip over any drive that it was not designed to flash.

My personal rule is always - if it ain't broke, don't fix it.

That rule assumes that it's easy for one to tell if it's broken or not.

The problem with this particular firmware bug is that it's a "silent" problem. If the drive identification command is issued when there are queued NCQ writes pending, then those writes in the queue are lost. No error is reported by the drive or by software. It's a fairly rare triggering scenario, so it's possible to run for a long time without running into problems, and once you do run into problems, it may be a long time before you discover that the data in a file is corrupt.

To compound the problem, Samsung, in their infinite wisdom, decided to not increment the firmware version with the fix, so unless you run some write tests (many of which are destructive in nature) while also issuing identification commands, it's hard to reliably determine if the drive is affected or not.

 

[nweissma]

The flasher is not dumb and it should skip over any drive that it was not designed to flash.

that same argument was implicitly ascribed to ubuntu a few years ago. i told ubuntu to install on D, and leave C alone ... the ubuntu install tsunamied *both* C and D. [C held vista]

If the drive identification command is issued when there are queued NCQ writes pending, then those writes in the queue are lost. No error is reported by the drive or by software. It's a fairly rare triggering scenario,

so unless you run some write tests (many of which are destructive in nature) while also issuing identification commands, it's hard to reliably determine if the drive is affected or not.

am i correct in saying that the hdd identification process is being invoked by the SYSTEM -- such as by a daemon -- rather than consciously by a user? i can't picture a scenario wherein a user writes a file to the hdd, and during the 15-30 second write, the user consciously decides to issue a drive identification command! the drive identification command must be being issued "subconsciously"? and another conceptual problem that i'm having is that it is my understanding that "NCQ" is associated with READS, not WRITES.

 

[code65536]

am i correct in saying that the hdd identification process is being invoked by the SYSTEM -- such as by a daemon -- rather than consciously by a user?

It could be invoked by the user. E.g., if you ran a utility capable of disk diagnostics (AIDA64, CrystalDiskMark, etc.). Or it could be invoked by a background process or service. Some software activation/licensing schemes that key an activation to your system's hardware might check a disk's identification. As for writes, there are writes that happen all the time. If you have memory pressure and memory is being paged out, that's a write. Receiving a cookie in a browser will result in a disk write. Visiting a website will result in writes to the browser's cache and history. Windows is constantly logging, and those are writes, too. And remember that at the low level, writes do not consist entirely of data: they often also involve writes to the file system's data structures that keep track of metadata, etc. So even if it's an unimportant temp file being written, there is the potential that you might end up with file system corruption.

Again, all this is dependent heavily on luck and timing. As such, if your drive is affected, the chances of actually being hit by corruption is low (and the chances of noticing corruption is even lower). Which is why this firmware bug survived in the wild for months before being discovered.

 

[nweissma]

so, how can i design a test to ascertain whether data is being lost on my hd204ui mfg'd april 2011?

 

[code65536]

so, how can i design a test to ascertain whether data is being lost on my hd204ui mfg'd april 2011?

I wouldn't bother with an April manuf date. I have two of these drives, one from April or May 2011, and the other from November 2010, and I only flashed the November drive. Samsung said that they should have the fixed code in their January drives, and April is a few months after that promised date, so I have little reason to believe that your drive in particular would be affected. Much of what I posted in their thread was for general reference and was not intended to signal distrust in Samsung's promises.

If you really want to do a test, I would suggest finding a few large files (a few hundred MB each), and hashing those files (e.g., using HashCheck). Copy those files to the hard drive (in parallel, to create some thrashing and increase the likelihood that there will be something in the queue), and during this copy operation, fire up AIDA64 and use it to look at information about your hard drive. After the copy completes, check the hashes and see if they match (you may want to reboot after the file copy, since there is a good chance that when you try to read back a freshly-copied file, you are actually reading from the Windows file system cache in the RAM instead of from the disk). I've never done this test so I am not 100% sure that it will identify an affected drive, but based on what has been reported about the nature of the bug, this test should work.

 

[energee]

There's another patch on Samsung's site for the F3 and F3EG models (e.g., HD103SJ). It's supposed to resolve an issue with certain chipsets. They mention "AMD SB850 chipset and Intel P67/H67" explicitly, though I would assume all Sandy Bridge are affected.

http://www.samsung.com/global/busine...bbs_msg_id=308

Unfortunately, there is _ZERO_ information provided detailing the nature of the problem, and to which firmware revisions the update applies. Navigating Samsung's site is a nightmare. I dread the thought of suffering an RMA process with them.

Have any of you applied this patch, or have more information?

 

[Golgatha]

do you have any thoughts about whether i can successfully flash the firmware while the HD204UI is in a usb 2.0 external enclosure http://www.newegg.com/Product/Produc...-042-_-Product

or is integration into the tower sine qua non?

call me chicken little but i am seriously worried about whether samsung's firmware patch might wreak havoc on an archival samsung 1tb hdd that is now integrated into the tower -- i really hate surprises and a surprsie of this magnitude will push me into a homicidal frenzy (a similar case a few years ago with an ubuntu install on D tsunamied both D and Vista C). i know that i can simply physically disconnect the archival samsung but i am academically curious about your thoughts.

My policy is to unplug all drives from the system you don't need to do the firmware flash on or with. It's a bit annoying, but it could potentially save you a huge headache.