Barracuda XT, Barracuda, Barracuda Green, DiamondMax and other desktop SATA and IDE drives

[Mastakilla]

Hi Cantbecanit,

Thanks for the answer.

The FW did not try to update the SSD. It did destroy the MBR on my SSD and by doing so cause fatal SMART errors to occur on my SSD.

The SSD still works, but according to SMART (and so also according to Windows and the Intel SSD Toolbox) it is broken and needs replacement.

This is the full description of the problem that I gave to Intel earlier today:

About a week ago I decided to upgrade the firmware of my Seagete Barracuda LP HDs from CC34 to CC35:

http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=213915&NewLang=en

To upgrade this firmware, you can choose between a MS Windows update tool and a Bootable CD Image.

To spare the empty CD, I decided to try the MS Windows update tool first. This tool "installs" itself in MS Windows and then asks to reboot the system.

Actually it had extracted itself and modified the MBR so the actual update tool could run before MS Windows boots.

However, after rebooting, I got the following error message: "Non-System Disk, press any key..." (see the attachment IMG_0283.JPG)

After pressing a key, it simply proceeded by booting into MS Windows. (so it did not update the firmware of the Seagate HD).

So I burned the Bootable CD Image after all and successfully updated the Seagate HD firmware with that.

When booting the system, the message "Non-System Disk, press any key..." kept on reoccurring.

I ignored this message for the moment (since I planned reinstalling MS Windows soon anyway) and started testing the Seagate HDs with the new CC35 firmware.

A day (or 2 days?) later (so a few reboots with the "Non-System Disk, press any key..." error later), MS Windows suddenly showed an error that my SSD was about to fail.

This was while the system was idling for about 30 minutes already...

So I opened the Intel SSD Toolbox and found out that the SMART attribute "End to end error detection count" was 1 instead of the expected 0.

I took following screenshot of this: http://users.telenet.be/Mastakilla/HDs/ssd_fail.jpg

I searched for "End to end error detection count" on google and only found a few people having the same issue directly after they updated the firmware of their SSD (and I already did that long before, so my issue was different).

So I called Intel for an RMA, they told me to contact the shop where I bought the SSD, so I started an RMA procedure with the shop...

The thing was: I kept on using the PC to continue testing and noticed that the "End to end error detection count" remained 1.

So I left it on for 2 days, did some more testing in meanwhile, but it stayed 1.

Then I rebooted and noticed that the "End to end error detection count" increased by 1. I noticed that every boot, it increased by 1.

That is when I made the link between the "Non-System Disk, press any key..." error and the "End to end error detection count" SMART attribute problem.

However, it is very weird that when MS Windows discovered the "End to end error detection count" SMART attribute problem, it only had the value 1, while I already rebooted multiple times after the "Non-System Disk, press any key..." started occurring (so actually a value higher than 1 was expected).

Next I googled for the "Non-System Disk, press any key..." issue and found the following topic:

http://forums.seagate.com/t5/Barracuda-XT-Barracuda-and/Non-System-Disk-Press-any-key/m-p/36306

This topic describes a similar problem to mine, but then the topic starter did not have any SMART issue and I do not have an HPA or Dell PC.

The command "bootrec /fixmbr" from that topic has fixed my MBR, so the "Non-System Disk, press any key..." error disappeared as well.

After this, also the "End to end error detection count" stopped increasing with 1 every boot.

However, the problem remains that "End to end error detection count" is in meanwhile 11 and according to SMART this attribute is only correct when it is 0.

All values other then 0 indicate a broken SSD according to SMART (and so also according to MS Windows and the Intel SSD Toolbox).

Yesterday evening I already explained the issue to the Seagate support and they were going to pass it to their programmers (I didn't get a case nr, so I'm not sure if they really will).

So, now my questions and concerns about this issue:

1) Is my assumption that the broken MBR is the cause of "End to end error detection count" SMART issues correct?

2) Is my SSD really broken? Do you advice to RMA it?

3) If you are 1000% sure that it isn't even nearly broken and that I should not RMA it, then how do I reset the "End to end error detection count" SMART value to 0?

I definitely do not want to let windows ignore the SMART error, cause then if "End to end error detection count" someday REALLY occurs, my MS Windows will not report it...

[Cantbecanit]

I think it's the ahci doing it bud, Seagate and Maxtor drives ime don't like NCQ (native command queueing) and this is what ahci is all about, that and being able to hotswap drives about.

It may well have wrecked the MBR doing the FW upgrading, I can't say for sure though, Windows diagnostics imo are a pile, same sort of system to a fault on a modern car, computer says one thing, but the fault lies deeper down the domino pack causing a part to report failed that isn't.

What I would do right now is this, I would run the SSD solo and see if it straightens itself out, if it doesn't I'd then format it and fresh load 7 to it again, then once I was happy it's running ok I would then go to the bios and run in an ide mode fully, jot down the existing settings btw, then plug the Barries in and see if they get recognised ok, if it all runs ok then, then go back and return the bios settings for ahci as they were before, if it all runs ok after that it's job done, if not and it runs ok under ide, I'd say it's the Barries now playing ball with the ahci settings.

I get this myself with a docking station using the eSata mode, my Samsung drives NCQ perfectly, but if I slave my Maxtor, or run it as C: unless I switch back to ide it hangs, this has been using two different MB's as well, same result, both Gigabyte ones.

Anyway, if you don't need the data, or have enough space to push it all onto one Cuda, I would clean house on the other two, and then see if they behave ok, and finally boat the data over to the other Cuda and format that as well, this way everything is fresh and at least then if it's still playing up you can confidently send the SSD in to Intel knowing it has a fault.

You may want to read up on the SSD btw, iirc the early ones aren't as bells and whistles as they are made out to be, iirc the Buffalo and one other that escapes me are the best ojnes, but they price point way above the others.

hth.

[fzabkar]

Mastakilla,

I don't see how writing to the MBR (a sector in the user area) could have caused a SMART End-to-End Error. AIUI, this error is indicating that data passing through the SSD's RAM cache has failed a CRC check.

See http://en.wikipedia.org/wiki/S.M.A.R.T.

That said, I don't like the idea of any application writing to the MBR on my drive without informing me beforehand. In fact I'm wondering why that doesn't trigger a warning from antivirus software.

[Mastakilla]

@ fzabkar:

I don't really understand how it is possible either fzabkar, but it seems pretty obvious from my observations that there is a real link between the 2 somehow...

With a broken MBR the value kept increasing every single boot, with the fixed MBR it stopped increasing.

The value is still 11 after a few more days and a few boots later

I agree btw that the firmware upgrading tool should warn more clearly before messing with the MBR. I probably wouldn't have tried the Windows tool if I knew that...

@ Cantbecanit:

I don't really understand your post. If AHCI prevents the Windows firmware update tool from not destroying the MBR, then I think it should be very easy for Seagate to simply build in a little check, no?

I don't think I'm the only one running these HDs with AHCI...

Also, it would surprise me very much if a HD nowadays wasn't compatible with AHCI. 5 years ago: ok... but now: no way...

And what do you mean with "What I would do right now is this, I would run the SSD solo and see if it straightens itself out"? I can't see how it can straighten itself out? The SMART value is 11. It doesn't increase anymore, even when not running solo. And as far as I know, SMART values don't reset themselves

"...run in an ide mode fully, jot down the existing settings btw, then plug the Barries in and see if they get recognised ok, if it all runs ok then..."

Once more: since I fixed the MBR, everything is running ok. The value doesn't increase anymore. The Barracudas work (except for the idle clicking of course and  of them not wanting to accept CC35, but that is a completely different story). So again, I really don't understand what you want me to test.

"Anyway, if you don't need the data, or have enough space to push it all onto one Cuda, I would clean house on the other two, and then see if they behave ok, and finally boat the data over to the other Cuda and format that as well, this way everything is fresh and at least then if it's still playing up you can confidently send the SSD in to Intel knowing it has a fault."

Don't understand this either? What does it proof about the SSD if the Barracudas work fine?

So... Sorry if I misunderstood you, but can you please explain what you mean?

About SSDs being too new technology:

I think it is widely accepted that Intel SSDs are the most reliable, best tested (by Intel and its many consumers) and most proven. The SSDs you have in mind are the ones based on the very recent controllers (Sandforce) or the extremely old crappy controllers (Micron)

The brand "Buffalo" doesnt say anything about the SSD, it's all about the controller inside...

[Cantbecanit]

What I'm suggesting is a clean set up, just incase it's a bad file throwing it all in the air, I mean to save your data to one drive while cleaning the other two, and then swap it over and clean the third drive.

Anyway, the two Seagate drives should be flashed one at a time and with no other drive connected, once you have both flashed, then you can put the system back together.

As you are probably using AHCI there is also a possibility the O/S isn't configured for it, you can regedit this to resolve it

This issue occurs if the disk driver in Windows 7 and Windows Vista is disabled. This driver must be enabled before you change the SATA/RAID mode of the boot drive.






Enable the AHCI driver in the registry before you change the SATA mode of the boot drive. To do this, follow these steps:

   1. Exit all Windows-based programs.
   2. Click Start, type regedit in the Start Search box, and then press ENTER.
   3. If you receive the User Account Control dialog box, click Continue.
   4. Locate and then click one of the following registry subkeys:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IastorV
   5. In the right pane, right-click Start in the Name column, and then click Modify.
   6. In the Value data box, type 0, and then click OK.
   7. On the File menu, click Exit to close Registry Editor.

It's all pretty easy to do, and it might help, worth a try before more radical action anyway.

AHCI if not configured correctly causes drives to drop out etc, so try this and see if things get any better, as far as the Intel SSD goes, I can't really say too much as I haven't used one yet, so I don't know how they behave tbh.

[Mastakilla]

Hi Cantbecanit

I'm still not 100% with you... 

Your suggestion to clean the drives is for fixing what actually?

It's kinda hard to see if something helps, if I don't even know what I'm trying to fix

Anyway... after the Windows Firmware Update tool failed, I used the  Bootable CD Image.

I did this with only 1 HD attached (even SSD detached) and with AHCI disabled.

I also already did the registry trick to enable AHCI.

I initially installed Win7 on my SSD with AHCI disabled.

When I tried to enable it later on, Win7 failed to boot, so I switched back to IDE, did the registry trick that you mentioned, switched to AHCI and booted successfully. This was about a month ago, before attaching the Seagate HDs...

[Cantbecanit]

I'm saying start over from fresh, this way you remove any virus/bad O/S things out of the problem.

Have you managed to flash the Seagate's yet, or are they refusing to accept the new FW?

And can you refresh me as to what is the exact problem you need to resolve, because I'm not a bit lost after the last reply with the wink alongside it.

[Mastakilla]

Hehe

I'm as lost as you about the problem

Actually there is no "real" problem.

The HDs work and the SSD works too...

The HDs do have the idle clicking problem:

http://forums.seagate.com/t5/Barracuda-XT-Barracuda-and/Idle-clicking-of-Seagate-Barracuda-LP-HDs-an...

But that is a completely different problem and also belongs more in the thread mentioned above (even completely empty HDs with only a power cable attached do this)

And the SSD has the issue of the SMART attribute being non-zero, while that attribute has to be zero for the HD to be considered working.

But again, cleaning up HDs, virussen, changing AHCI setting, cleaning up the SSD, those things all don't change the SMART value... The SMART value will never become zero again... (unless by some special hack, which I will only WANT do by direct instruction of Intel.)

What I'm now trying for the SSD (using the Intel Helpdesk) is figuring out if it is really broken, or if it just thinks it is broken... If it just thinks it is broken, but actually is 100% sure 100% working, then I may try to force the SMART value back to 0 with direct instructions from Intel. But if there is any uncertainty, I don't even want to "fix" it, cause then I'll just be hiding a potential problem... (It is not because an SSD is broke, that I have to notice it right away...)

If not, then it will be an RMA...

actually the main reason for sharing my experiences in this thread, wasn't for getting help (only Intel and perhaps the person who created the Windows Seagate Firmware update tool can do that).

it was for letting people know what happened to me and informing Seagate that their faulty software destroys SSDs...

About the 2 HDs refusing the  CC35 firmware upgrade: that discussion is more something for the other thread (see above).

I actually just received a 2nd confirmation from Seagate email support today, that they are suggesting me to force the firmware upgrade to CC35.

So I will try that this evening...

Not that that will solve anything, cause the 2 HDs having CC35 already, are still clicking...

[zekas]

well, Seagate is making crappy software.  windows version of Seagate HDD FW upgrade corrupted my PC's HDD MBR the same way as in Mastakilla's case.

besides there is a difference between chinese and thailandese made disks ST32000542AS.  vendor of our NAS suggested upgrading their FW from CC34 to CC35.  but the only HDD that was upgraded was the one that was made in china (s/n 6X*). bunch of others made in thailand (s/n 9X*) that utility did not upgrade, although all of them are of the same P/N and all had the same FW.

one more thing, https://apps1.seagate.com/rms_af_srl_chk/ serial number check utility must be months outdated because it did not issue any FW upgrades for bunch of ST32000542AS although such upgrade exists (CC34 -> CC35).

i am completely dissatisfied with Seagate support and would not recommend anyone buying Seagate disks.

[AlanM]

Well, a different and later firmware version exists, yes, namely CC35, but only certain firmware versions are field-upgradable, and CC34 is not among them.  Sorry to be the bearer of unpleasant news.