Samsung 2TB green drives defective firmware?

I have 3 running in a WHS homebrew and everything seems fine so far; been running for about two weeks. I have also updated the firmware before installation.

Edit: I have not messed with aligning the sectors either....

Same here.
 
I had a lot of trouble booting into DOS on my Win 7 64 PC, but I was finally able to apply the patch to both my F4s ("Drive 1" and "Drive 2"). However, I didn't know I should have set the bios to IDE so it was left set to ACHI (no raid - I just hotswap a lot). I got the "download successful" message, etc., but there's a couple of things that make me wonder if the firmware got screwed up.

First, when I go to the info screen in HD Tune 2.55 (free), one of the drives does not have the interface power management smart feature checked.(see F4 Drive 1) The other drive has that feature checked (see F4 Drive 2).

Second, when I use Crystal Info, both drives show up as "disk 1" or "disk 8" rather than the drive letter shown as with my other hard drives. (see Drive 1 CrystalDiskInfo and Drive 2 CrystalDiskInfo)The F4s are the only ones that do this. All of my other hard drives, including four other Samsung’s (two F3 1TB and two F3EG 2TB) show up with drive letters. I'm almost certain that before the patch both F4s were listed with drive letters rather than SATA port numbers.

Other than that, the drives seem to work okay, though I did find some CRC file match failures on Drive 1.

I'm worried that something got screwed up when I patched the firmware - particularly "Drive 1" since HD Tune does not show all smart features properly enabled. The lack of a drive letter in CrystalDiskInfo may not mean anything, but still...why does every other drive show one?

Should I be concerned? Did something get screwed up with the drives and so I should RMA Drive 1 or both to be safe? I'd prefer not to RMA either since I have had bad luck with RMA/refurb drives (not to mention spending 9 hours to test & transfer the data). Still, better that than a crashed drive later on.

Any help is greatly appreciated. If some other F4 owners could let me know if they get the same results with HD Tune (i.e. whether all smart features are checked or not) and CrystalDiskInfo (whether the F4s are listed with drive letters), that alone would be a big help.

Thanks.
 
I just ran HD Tune 2.55 on my two F4's and they have "Smart" checked.

BTW, both of my drives are in a homebrew WHS and I updated the firmware before adding them to the storage pool.
 
If I use a utility in windows to scan my disk for bad sectors, would this detect any data corruption caused by the firware bug and use of SMART software?

quote

"I suspect that most SMART software would issue the identify command.

Unless you are using the drives in a configuration where parity / checksum info is saved, such as a RAID5 array or certain filing systems you can't tell if any data is corrupted. Well not unless you have another copy elsewhere and you compare checksums."
 
For anyone having the the error I was having on my Crosshair iv, I changed my drive to the jmicron port on the board and the firmware update completed on both of my drives. Weird that the main continued wouldn't pass the commands.
 
If I use a utility in windows to scan my disk for bad sectors, would this detect any data corruption caused by the firware bug and use of SMART software?

No as the bug just caused data not to be written in certain cases. It does not cause bad sectors.
 
I just ran HD Tune 2.55 on my two F4's and they have "Smart" checked.

BTW, both of my drives are in a homebrew WHS and I updated the firmware before adding them to the storage pool.

When you say the have "smart checked," are all the smart features checked - particularly the "interface power management" feature? Since that's checked on the other one, I'm 99.99% sure it should be, but it wouldn't hurt to have another example.

If you don't mind, would you (and anyone else with an F4) please run CrystalDiskInfo (DL here CrystalDiskInfo]), and let me know if you get a drive letter or if you get a number like "Disk 1", "Disk 3", etc.? I have just a few days left to exchange "Drive 2," and if other people show an assigned drive letter in CrystalDiskInfo, then I'm going to play it safe and exchange it. If people get a number with patched firmware, then I guess I'll keep it.

Please let me know about the above when you can and thanks for the reply.
 
Update: I bought another F4 in case I needed to RMA both drives. I installed it immediately and HD Tune showed the interface power management smart feature checked, and Crystal Disk Info listed it as "Drive 8" (same results as "Drive 2" in my earlier post). I patched the firmware and got the same results. So I guess the fact that Crystal Disk Info gives a number (SATA port #?) rather than a drive letter is just an anomaly with that program and F4s. Strange, but whatever. So "Drive 2" seems to be okay and I'll keep it.

I'll RMA the other F4 Samsung. Maybe the fact that HD Tune doesn’t show that smart feature present is really nothing, but I know I've had some CRC file match failures with that drive. It's not worth the risk that something may be wrong. I've got far too much data to lose. Unfortunately for me, the F4 I just bought has a LOUD hum (drowns out everything else entirely). It starts right after boot up and remains regardless if the drive is in use or not. So RMA that one to NewEgg as well. I really hope that Samsung quality isn't starting to drop. I've had zero issues with my four F3 drives,

JMO, but this issue has been nothing but PURE FAIL by Samsung. First requiring a DOS boot to patch is ridiculous. Requiring DOS for ESTools is utterly unacceptable. DOS has been gone for what? Over a decade? Neither WD nor Seagate require a DOS boot for their firmware patches and certainly not the software. LMAO at the fact that the "instructions" state to make sure the F4 is set as the "primary/master" before patching. HUH!? It's a SATA DRIVE!!! Maybe the fact that Samsung still thinks that new HDDs still use IDE explains why they still use DOS for patches & software. It's 1999 all over again. The patched firmware has the same exact version number as unpatched. I just bought an F4, and I had no idea whether it was patched. What about my RMA drive? What about a drive bought two months from now? Just stupid not to add an "a" or "v2" to the firmware version. On top of it all, Samsung provides ZERO notice to F4 owners on the USA website. Even on the global/HDD site the problem is buried in some FAQ. Sorry to complain, but this “little” issue has cost me a LOT of time. Another 8-9+ hours wasted this weekend alone transferring files to other drives so I can RMA the one drive.:mad:

I read somewhere that Samsung is supposed to issue a true firmware update this month. I hope that's the case and they get the F4EG quality back up. I can't find a good alternative to this drive - especially for the price. I don't trust Seagate anymore (plus mediocre performance). The WD Caviar Black 2TB is LOUD, has vibration issues during multiple read/writes (already RMA'd one due to severe vibration and the replacement while better, still vibrates more than any other drive in that situation), is way over priced (twice what a Samsung F4 2TB costs), offers little, if any, increase in read/write speed, and still uses 4 platters.

Lastly, I want to say THANK YOU to the forum here. If not for this thread, I would have NO IDEA about this issue. I could have lost a terabyte or more of data that I can’t easily replace or even replace at all. I back up all my data, but if what you are backing up is corrupt from the start, it doesn't do you much good. Plus, half my data drives are F4s so in some cases I’m backing up from one F4 to another. *sigh* I really wonder whether I need to look into a Blu-Ray burner and back up that way.
 
I am having some issues with my (updated) HD204UI drives. The four drives are in RAID 10 using my Intel onboard RAID controller. When I pull a drive, everything works fine, then I put the drive back in, rebuilding starts and afterwards I get all kinds of NTFS corruptions.

It could be that the Intel RAID is just a big fail, but perhaps the controller issues some SMART commands and the HD204UI fails to write data at those points, because the corruptions aren't throughout the whole volume. At this moment I am not sure what causes this problem, but I suspect it's the HD204UIs acting up, because I can't really find any threads about Intel RAID 10 issues anywhere that are similar to mine.
 
Did you run a parity check / repair on all the drives before pulling one? If you have errors which arose before you patched the firmware when you pull a drive there won't be any parity information to correct any errors.

On the basis that there have been extensive tests on the new firmware which haven't indicated any issues I would suspect your problems are due to something else. Perhaps if you post more about your configuration someone may be able to help.
 
I got the drive last week and this update seems pretty complicated. Is there anyway I can do it through my eSATA dock or do I have to unplug my other hard drives and boot it from that way.
 
Ok I got that DOS screen that was posted up before and its still showing same firmware in HDDScan. Should I try again?
 
Did you run a parity check / repair on all the drives before pulling one? If you have errors which arose before you patched the firmware when you pull a drive there won't be any parity information to correct any errors.

On the basis that there have been extensive tests on the new firmware which haven't indicated any issues I would suspect your problems are due to something else. Perhaps if you post more about your configuration someone may be able to help.
Is there even any parity info on a RAID10 array?

All four of my HD204UI drives are brand new and patched using F4EG.EXE before first use. So they were patched before being added to the array. The array was built just one day before I pulled one drive and neither chkdsk nor Intel Matrix Storage Manager shown errors beforehand I pulled the drive. After pulling the drive, then running chkdsk (with three drives) shown no errors. When re-adding the missing drive, the array started rebuilding and after waiting for about 6 hours it was done. I then ran chkdsk on the 4TB GPT volume and it gave all kinds of NTFS errors. Then I used verification and repair in Intel Matrix Storage Manager and that shown NO errors.

My setup:
- Asus P7P55D w/ Core i5 and 12 GB of memory (not that the latter should matter)
- Intel ICH RAID (onboard)
- 4x HD204UI with latest firmware in RAID 10 (updated using F4EG.EXE prior to building the array)
- 1x OCZ Vertex 2 60GB as JBOD on the 1st port
- 1x iHAS224 DVD Burner on the 2nd port
 
It is not possible to "repair" a RAID10 (or RAID5) without additional external information (such as a drive reporting a read error for a specific block), as there are only 2 copies of each block. One can "scrub" such an array (such in making it consistent again), but you can not tell if it replaces the wrong or the right block. A RAID 6 or a 3-disk RAID1 however can be repaired as long as there are all drives in that array (because there are 3 copies of each block), but I don't know if there is an implementation that makes use of this.
 
Interesting to know. Are you sure that it isn't possible to repair a RAID5 as surely the parity information allows the correct data to be reconstructed?
 
Ok I got that DOS screen that was posted up before and its still showing same firmware in HDDScan. Should I try again?

The firmware revision # should be the same after the upgrade. It is a little frustrating that samsung left it that way but the patch does work. I have verified the patch on 3 drives using the "how to reproudce" test that is found on the smartmontools site on the first post of this thread before and after applying the test.
 
Interesting to know. Are you sure that it isn't possible to repair a RAID5 as surely the parity information allows the correct data to be reconstructed?

No, single parity allows you to determine that there was an error, but does not contain enough information to correct the error.

Consider this:

1010 original data, with convention that last bit keeps parity even

1110 error introduced in 2nd bit, note that parity is now odd, so we know there was an error

But how do you know which bit had the error? We only know because I just told you, but if I left out the first line, and said here is 1110, which bit is in error, no one could answer.

If you provide additional information, like the error was in the 2nd bit, then you can reconstruct the 2nd bit (that is essentially what happens in RAID 5 when a drive dies, you KNOW which drive died, so you can fix it)

You need more than single-parity (like RAID 5) to correct an error. As omniscience said, RAID 6 has enough information to correct an error.
 
Last edited:
Thanks, that makes sense now you have explained it.

This unfortunately mean that the mismatches I thought mdadm had fixed on my RAID 5 array may well not have been properly corrected. At least the vast majority of my data on the array is multimedia where it isn't fatal if there is an odd error.
 
The firmware revision # should be the same after the upgrade. It is a little frustrating that samsung left it that way but the patch does work. I have verified the patch on 3 drives using the "how to reproudce" test that is found on the smartmontools site on the first post of this thread before and after applying the test.

Thanks! This is a pretty ridiculous situation though.
 
Still having trouble with firmware update... Don't know why but those instructions for flashing it are not working for me :(
 
Are you booting from a freedos cd? Do you have your firmware on a usb stick? Is your samsung f4 connected to a normal SATA controller and not a raid card?
 
Last edited:
So how many of you are running these drives in a WHS box? It seems there are one or two other threads in this forum that don't recommend these drives for WHS.

Thanks

I just ordered 12 of them along with an areca 1680ix. I was planning on using WHS. Ill let u know how it turns out.
 
Can anyone tell me if I need to unplug all my other Hard Drives before proceeding with this firmware update?
Thanks
 
I don't have first hand knowledge (for a day or two), but I'd read elsewhere that you didn't have to, the patch only looks for drives it will work with. One example had an F3 plugged in and it ignored it.
 
Can anyone tell me if I need to unplug all my other Hard Drives before proceeding with this firmware update?
Thanks

No. It ignores all other drives. Well when I plugged it into a system with 2 F4s, an Intel X25-m, a seagate 7200.11 and a WDC black the only drives it updated were the F4s..
 
No. It ignores all other drives. Well when I plugged it into a system with 2 F4s, an Intel X25-m, a seagate 7200.11 and a WDC black the only drives it updated were the F4s..

Thank you. I also have a couple of F3's in there and didn't want to have to open up my rig to unplug 'em.
 
Yeah, did mine today. I unplugged my other drives to be paranoid and forgot about my SSD, and it came up with a message noting it was a non-samsung drive. Unfortunately, the update didn't want to work with my eSATA controller I guess, it wouldn't see the samsung when I tried using my TT dock, so had to do it the hard way, open my case, and plug the drive into an onboard port. Then it was a piece of cake, no more than 10 seconds to flash. The job definitely goes faster with a USB boot flashdrive than having to boot to a CD for flashing.
 
Does anyone know if any of the defective drives are still in the supply chain? Can we assume that Samsung are flashing all new drives with the corrected firmware? Do you think a three or six month wait would be long enough?
 
I think the we will have to wait till the firmware revision # changes to be sure. However it only takes 5 minutes to verify if the bug exists and about that time to update the firmware so its not like a big hassle or anything. I guess unless you have the drive in an external enclosure that does not expose SMART. However in that case you are likely not to suffer from the bug. Please do not quote me on that. Not verified.
 
I have 2 F4's, one purchased from NewEgg and the other is from a local vendor. One started having SMART errors today, followed by the 2nd one.. Became very nerve racking, very quickly.... I don't like to loose data.

• Both drives have about 160 hours on them and are flashed.
• After a power cycle, the errors went away on one drive
• One Samsung F4 had a spin up problem and has generated fail errors in the smart table.
• Only the Samsung drives had problems. The WD and Hitachi drives were normal.

Needless to say... I lost a lot of time today dealing with something I don't yet understand. I'm going to head down to Frys and pick up a replacement to back up the data and send the problem drive back to NewEgg on RMA.

Damn... These drives may be too good to be true... Hopefully not the next deathstar.
 
I did the update last night after I got in the drive. From reading here, it's ok that the firmware number hasn't changed. I would like to test that the drive is 100% before trusting it, but I've never used HDDScan.

I clicked SMART and everything came back green. Are there other tests I should run?
 
I am trying to flash the new firmware and am getting an error.

I have a Samsung HD204UI with 1AQ10001

"This system supports ATA command only.

This Program isn't available for this drive?"

Anybody still having this problem: switch to AHCI
 
And I've seen others say to have it on IDE when flashing...so whichever you're on, try the other. :)

Also if you're on eSATA, try an internal connection. I picked a bunch of these for a RAID when they were on sale at Newegg this week, tried patching them on my external dock and the patcher wouldn't see the drive. Once I connected it to the Intel controller on an internal connector, it worked fine.

They seem to be nice drives, they're silent. Only noise I really notice is the goofy noise they make on spinup.
 
Comments over on the Unraid forums appear to be having the same problems...As mentioned above, the issue is that there is no real difference in the naming conventions between the drives shipped with the weird/jittery firmware, and the supposed fix;

That's kind of silly to be releasing a firmware if you can't verify that the flash even updated at all.
 
The smartmontools site in the first post has a "How to Verify" procedure that can be run in 5 minutes if you have a system that has a bootable cd rom and can download basically any current linux livecd or even systemrescuecd. It does require that you have some understanding of linux but its pretty simple.

Note: The dd command will destroy your partition table so backup before attempting. Or you can do it with the output being a file instead of the whole disk. I can explain how to do that if anyone wants.

If you do not want to go that route. dd, hdparm and smartmontools are all available for windows.
 
I'm still lost on this. I can run the patch, but I can't tell if it was successfully applied. I thought that if you patched it correctly, it wouldn't patch again. Period. That's true if I run it again right away. However, I power off the PC and then boot to DOS again, I can run the patch per usual. I'm booting from a USB boot drive created using the HP USB flash tool and the Win 98 boot files from ExtremeOverclocking (nothing else worked for me). I can only power off via the power button rather than a command, and I wonder if that's screwing up the patch.

Would someone please let me know whether the fact I can run the patch again and again (as long as I turn off the PC and then restart) means it didin't work? Is there any way to verify the patch worked other than use the Smartmontools test? I have no idea how to even attempt doing that.

I really need to get this issue solved as I use this PC for work and personal.

Thanks.
 
I can verify that even after a successful patch, you can continue to re-patch the drives after a reboot. The ONLY way (that I'm aware of) to functionally verify that the patch was successful is to use the SMART test (and even then, you can only really be certain when the test fails... you can never prove a positive hypothesis in this way).
 
Back
Top