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

[modestos]

Hi,

I own 4 Baraccuda LP ST32000542AS drives. All drives click while 2/4 locked themselves - all of them seem to be affected from the 0 LBA/BSY fault error.

The proccess seem to be the followin:

Drive clicks -> reallocating sectors -> Event Log goes at 320 or some multiple of 256 -> "Assert Failure" and the drive hangs as a failsafe measure

The first drive was identified by the BIOS with 0MB and 0 sectors (as ST_M13FQBL or bzbzbz). On operating systems (windows/linux) the drive showed up as having a capacity of 3.86GB. OS was complaining that the drive cannot be initialised (its contents cannot be accessed in any way). The drive gave me a Seatools error code 9DEBA96B which is a short test LBA error.

All drives came with firmware CC32.

I tried upgrading to CC35 and clicking behaviour stopped as well as sector reallocation, but seatools propose to RMA drives.

Is this a CC32 firware bug? What should I do with locked drives?

mod

[Cantbecanit]

Return them, it looks like they are done for tbh, the MS13FQBL message isn't due to bricking, test them all and collect the codes they give you, if you have them in Raid, Raid can mark a drive out as bad as well, so that might be worth checking out as well.

[modestos]

This appears to be a replica of the 7200.11 firmware problem:

http://www.milos.ivanovic.co.nz/blog/218

http://forums.techarena.in/hardware-peripherals/1453683.htm

Why do drives, that have not been bricked, work fine when upgraded to CC35?

Seems to me a cc32 firmware bug.

mod

[modestos]

thx for the answer , btw.

No, I donnot have them on Raid. They are on different machines (three of them) + one on external usb enclosure.

[milosi]

Hello modestos,

Thank you for spreading awareness of this issue by linking to my blog on the topic in your earlier post. As you already know, I had what I believe is the same issue, with the same drive, and was able to resolve it with ease once I knew what I was doing. The only thing that is preventing me from really persuading you to try the method I used to solve it is that you have mentioned your drive is clicking. Mine did not click in any failing manner; it made all the normal noises a hard drive should make as it starts up (which is all it could do at the time).

If you could clarify what you mean by "All drives click while 2/3 locked themselves" that might help me and/or others identify your issue more precisely and suggest some steps for you to take to try and resolve it. Regardless though, the only thing I can personally suggest at the moment is what you already read on my blog post. Even though the word 'format' made me think I was going to lose my data, after significant research on the topic I had enough confidence that it was worth the risk, and having followed the instructions exactly as stated I was able to get my drive to work just like it used to, with health tests once again calling it 100% healthy.

If you have any luck getting the drives identified in the BIOS, update the firmware immediately if yours is out-of-date otherwise the issues may reappear later on.

Good luck. I will intervene further if I can help.

P.S. If you (modestos) or a forum administrator have permissions to modify forum post titles, please fix the model number to say ST32000542AS rather than ST3200542AS as the latter is not a valid Seagate hard drive model. If this is not changed, other people with potentially the same issues could miss out on valuable information relating to the exact same drive(s) they possess.

[modestos]

Hi milos,

Drives actually click from time to time, not continuously. (especially when I try to write/read large amounts of data)

Is there a possibility that your drive where clicking too, before fixing/upgrading firmware, and then eventually locked itself up?

Whether LBA 0 happened because the drive was clicking or the reverse, remains an unanswered question. But as I mentioned earlier, sounds resonable to think that:

Drive clicks -> reallocating sectors -> Event Log goes at 320 or some multiple of 256 -> "Assert Failure" and the drive hangs as a failsafe measure

The fact is that the drives reallocate sectors and lock themselves up.

This means that 2/4 drives appear as 0MB to BIOS. Windows/Linux identifies them as 3.86GB. (No data).

I tried upgrading firmware, on a working drive, from CC32 to CC35 and clicking behaviour stopped as well as sector reallocation. Copied lots of data, run several tests with no problems.

Crazy but, I will try to downgrade back to CC32 and see what happens.

Thx for responding.

[milosi]

I am having some trouble understanding the individual situation of all 4 of your drives.

Here are some initial clarifications:

• 0 LBA means that the drive is not correctly displaying its capacity to the BIOS and therefore any underlying operating system. Both will believe the drive has 0 sectors and therefore 0MB of total capacity.
• BSY means that the drive has become internally locked and will not identify itself to the BIOS AT ALL; that is to say, its controller is busy and does not respond to the BIOS' identification probes. It will not show up in the BIOS AND it will not show up in any underlying operating system.

You have said that you believe all four of your ST32000542AS drives are affected by the 0 LBA problem. This cannot be the case, as you mentioned being able to transfer data between one or more of the drives. If you are able to access any data on the drives, then they have neither of these issues.

Please try and answer the following questions in order to clarify your situation:

• How many drives show 0MB capacity in the BIOS?
• How many drives show up as ST_M13FQBL with a size of 3.86GB?
• How many drives can your operating system identify?
• How many drives have data that is accessible in whichever operating system you use?
• Do any drives fall in several of the above categories? If so, which drives and which categories?

If you can answer that succinctly, we may be able to help you further.

P.S. In answering your question regarding clicking: I have never experienced any of my drives clicking irregularly, even right before I had the problem. I upgraded my firmware while I had the problem, to no avail, but as I have said I did end up fixing my instance of the 0 LBA issue using methods described on my blog post.

P.P.S. I personally would not play dice with my data; if you have valuable information stored on there you should not be downgrading the firmware!

[modestos]

Ok yes, I will try to clarify the situation, cause it is obviously a bit complicated.

I have 4 identical drives. All with CC32, all have issues realllocating sectors. Sometimes they click(ed). No BSY.

I suspect that all drives have some kind of a problem, I guess firmware bug.

• 2 drives have the LBA 0 problem. Are visible to the Bios, not to the OS (3.68GB). (upgraded them from CC32 to CC35 successfully, but drives never came back to the OS, still 3.68GB)
• the other 2 Drives work fine, are identified both by the BIOS and OS, but reallocate sectors from time to time (from SMART results).

I have valuable data on the locked drives, unfortunately.

I obviously emptied the other two drives (working ones), and thus I experiment to find out what is going on with the firmware.

Any help is appreciated.

[milosi]

From my experience, upgrading the firmware will not fix your drives immediately, but it should prevent the 0 LBA issue from reappearing once the drives are fixed. I can only suggest that you perform the same actions I did to try and get your two 0 LBA drives up and running; it seems you more-or-less have the same symptoms I did. Only once they are working again will the firmware revision matter, as having the old firmware will just create another ticking time-bomb for the bug to reappear.

If a drive's reallocated sectors count is increasing, it means its likelihood of having an electromechanical failure is becoming more likely, and it is just a probability and not a definite fact. It is not related to the 0 LBA problem or the BSY state, but part of a normal hard drive's life cycle. If you are taking good care of your drives, this is not something you can control, only something you can prepare for.

If you want to take the risk, try what I did, and post the results, but it's your choice, and I'm not liable if it causes data loss.

[modestos]

I managed to fix one of my drives by following Milos's tutorial. thx Milos!!

I must admit that the drive is not faulty. This was a firmware issue, identical to the 7200.11 flaw.

For my other drive, I requested Seagate Data recovery (Holland) services to give me more information regarding these matters, but they refused to collaborate.

They actually kept the drive I send them for evaluation and now they refuse to send it back. I only spoke to "case managers" that never mentioned anything technical regarding the actual status of the drive. Their responce to firmware bug was a general answer of "other errors".

Now they ask for +800EU for recovery services for a well known issue that seems to affect several generations of seagate drives.

This is very sad!