Shamil's Blog. Software Engineering Processes, Android, CI, Devops.

I've recovered all data from my Maxtor Diamond max 22 (Seagate 7200.11 clone), see this link for details. The HDD was locked due to Seagate firmware problem (BSY status error). Finally, I've used commands from this guide and Siemens M55 RS-232 cable. Also I asked my friend to make a MAX232-based scheme, but it was incompatible for some reason and I've fallen back to phone cable (which was the backup solution). I did not get the LBA 0 problem after fixing BSY state error.
So if you have this problem, drop me a message in comments to get details on procedure, I will try to help you.
UPD: here's cool video guide (using Nokia USB cable and they disconnecting head block while I disconnected spin motor - result seems to be the same).

Labels: 7200.11, BSY, data recovery, hdd, maxtor, seagate, success story

The main problem that is logically result of what the GTD (getting things done) pronciple solves is the having to worry about multiple things (tasks) at the same time when one is best in solving only one task at a time, not good in solving two tasks same time and much worse than good when one need to solve multiple tasks. Some call this as dispersion, and I like to call this the "support hell", because this always appears when building some complex system.
From the first sight, I see two ways of solving this problem. The first one is described in GTD principle: to "... move tasks out of mind by recording them externally". This is, if to talk about building complex systems, is transferring of responsibility for each part (or some parts) to somebody else. But seems that this is not clear solve of the problem: actually, instead of being responsible for making parts of system to work, you makes someone else responsible for the same. Therefore one is not relieving the responsibility, instead one changes it with responsibility to control others make their work the right way. Sometimes this is better.
The second way is to build system parts that does not require much maintenance during ordinary functioning (a kind of "high availability" system). The breakdowns, of course, require one's attention.
The second way require much more technical skills to build the system but less (at least theoretically) work for the ordinary maintenance.

I've just read this Computerworld article and made these two charts (using google chart api, which is relatively simple, but does not show any syntax error, which sometimes hard to find inside the debris of chart image HTTP GET parameters :-) ) of failure rates. First one is for different manufacturers (for comparision) and the second one is about aging of hardware.

Labels: acer, apple, dell, failure, hardware, hp, notebook, sony, toshiba

Update: affected models (not serial numbers): ST31000340AS ST31000340NS STM31000340AS ST3750330AS ST3750330NS STM3750330AS ST3750630AS ST3500320NS STM3500320AS ST3640330AS ST3250310NS STM31000334AS ST3640530AS STM3320614AS ST3500320AS STM3160813AS ST3500620AS ST3500820AS ST31500341AS ST31000333AS ST3640323AS ST3640623AS ST3320613AS ST3320813AS ST3160813AS.

If you like to check whether your hdd is affected by a Seagate/Maxtor firmware fault, use this short tutorial.

Enter your drive's serial number here into: Seagate's firmware update check tool (https://apps1.seagate.com/rms_af_srl_chk/). After that, follow the instructions. If you see "No action required", your drive is not affected by the firmware fault.

How to know your drive's serial:

Linux

I use startctl (http://smartmontools.sourceforge.net).

smartctl -i /dev/sdX

(press TAB after dev/sd and enter your drive number from the given list, for example /dev/sda. However on different distros hdd filename differs, so ou may need to refer to docs). In output of command you'll see your serial:

Serial number:      9RA21232

Windows

I use Seagate DriveDetect.
Here's a screenshot of how output should look like.

In any case, back your data up regularly!

Labels: failure, hdd, seagate

I have Maxxtor Diamond  Max 22 500Gb (STM3500320AS model with "mx15" firmware).

The problem this model has is same as in Seagate 7200.11 series: some counters in system area overflow... and microcontroller disables all IO operations to prevent data loss (which is, of course, logicallly thinking, good idea. But the criteria does not seem to be the right). Therefore, all data is stored OK inside bricked HDD. 

Symptops: HDD BUSY led are being turned on during computers seeks for HDD on startup, this process is VERY long and ALWAYS ends with either a message "boot device not found" (if affected HDD is a system one), or system loads, but affected HDD is not detected by the system (at all, not only partitions, but THERE'S NO ANY HDD detected, even with specialized Seagate's Tools, or DriveDetect utils).

This is it, so-called "BSY" failure. The HDD is brick now :-)

Now I've restored my system partition from backup and waiting for my friend to solder the RS232-to-TTL (COM - to - service connector) signal convertor. I've also found the needed Seagate service commands to unbrick the HDD with BSY error.

Please check whether your HDD is affected and in any case: BACK your data UP regularily!

Labels: backup, BSY, error, failure, hdd, maxtor, seagate