Seagate 7200.11, fixed BSY twice before, new problem?

[Hazor]

7200.11 ST3500320AS, SD15

I'll start by saying that it has gone into the BSY state 2-3 times before, and I have successfully fixed it each time - and each time telling myself that I'd get around to applying the SD1A firmware ... then forgetting. RMA isn't an option as it's OEM. I've been searching/reading for 2+ hours now with no solutions found - sincerest apologies if I merely haven't happened across the solution..

Now, I've got it all hooked up with a notecard blocking the motor contacts, as I did each time before. I supply power to the HDD, wait a few moments, and press Ctrl+Z. Instead of being able to enter commands (e.g., /2) I get::

(Pressed Ctrl+Z)
F3 T>

F
3 T>
F3 T>Arch Linux 3.1.9-18-ARCH+ (ttyAMA0)
LED:000000CC FAddr:0025BF67
LED:000000CC FAddr:0025BF67

At which point I can not issue further commands. I have ensured isolation of the motor contacts and tried also removing the pcb such that both sets of contacts would be isolated, but I still get the same error. I even tried screwing the pcb back to the drive and doing it with all contacts contacting - as expected, it gave another LED:blah error which corresponds with the BSY state (LED: 000000CC FAddr: 0024A051 I think?)

I suspected that minicom was unwittingly trying to send some kind of greeting (perhaps along the lines of "\n\nArch Linux 3.1.9-18-ARCH+ (ttyAMA0)"), but I can't determine that minicom does such a thing and the only seemingly related concept is something called an 'init string', which was already blank. Still suspecting such a possibility that I just couldn't figure out, I tried a second serial console called ckermit. Its output is as follows:

(Pressed Ctrl+Z)
F3 T>

F
3 T> [whole bunches lots of garbage characters]

At which point I can not issue further commands nor even interact with the program and must kill the process.

Other potentially relevant information:

The previous times I did it all with a WinXP tower using hyperterminal and the rs232-ttl converter from alldav.com, supplying 5V from the tower's PSU. I think I fried that converter by accidentally reversing the power polarity (...reasons like this are why I elected to major in psychology instead of computer engineering) as it will no longer do a loopback test.

As such, this time I am using a Raspberry Pi (www.raspberrypi.org) and its UART pins (uses 3V3, interoperable with TTL), running Arch Linux and using the program Minicom. However, because I am able to connect to the drive and receive an LED:00blah error from it, I do not believe that the change of hardware/software is related to the problem.

I have re-re-re-re-checked the wires and the serial port settings. I tried with hardware flow control both on and off, and get the same error.

So, am I completely missing something/doing something wrong? If not, anyone got any ideas?

[bphlpt]

1) You have changed everything in your repair configuration except the broken drive itself leaving no common elements from your initial times you "fixed" the drive.

2) The drive has been broken two or three times before, so I wouldn't say it has ever been "fixed" just made temporarily operable.

I have been fortunate that I have never had to deal with this issue, but from what I understand I thought that the purpose of doing the "fix" on the drive was merely to hopefully be able to get the data transferred off the drive. Any further use of the drive was to be considered totally a temporary gift and the drive was very likely to fail again, as your experience has proven two or three times. If what I have said is correct, then you have been fortunate to have gotten as much use out of the drive as you have and it is now time to put the poor drive out of it's misery and give it a decent burial at your nearest recycling center. May it rest in pieces.

Cheers and Regards

P.S. If I am wrong I'm sure someone else will post accordingly.

[jaclaz]

P.S. If I am wrong I'm sure someone else will post accordingly.

Well, you asked for it, so, yes you are WRONG.

The original issue is about a firmware bug that simply "bricks" the driver when a log reaches a certain entry number 320*n+256, more details are here:

IF the disk is affected EXCLUSIVELY by the mentioned bug, it will brick every 3 to 9 months on average and can be re-unbricked all the times.

BUT the "bricking" may be due to OTHER reasons.

AND the "unbricking" procedure may temporarily provide "relief" to this other condition (just enough to hopefully get the data back).

@Hazor

The "garbage" is connected normally with missing or badly implemented GROUNDING.

Check, re-check and triple check that proper grounding is effective.

Read attentively the read-me-first, particularly point #7:

jaclaz