Hey

I have a failed Barracuda 7200.12 harddisk here. It spins up fine, stayed spinning but is then not recognized and not accessible. Did not ID to the BIOS.
The serial terminal showed no error messages at all when spinning up the drive. Access via Ctrl-Z was easily possible without covering the head connector.
I figured I give it a last ditch effort with the firmware fix I used before on 7200.11 drives with great success. Turns out I might have made things worse

The commands I applied were "N1" and "m0,2,2,0,0,0,0,22". I shouldn't have used the last command, but I only learned that after I did .

Now, the drive spins up fine and stays spinning, but still isn't recognized and repeatedly clicks every two seconds. Two times I managed to have the drive show up as "ST21000524AS", but with zero size and completely inaccessible. I can't reliably reproduce that. No error messages in terminal, only "Rst 0x20" and "(P) SATA Reset" as the last message.

Can I still try anything to maybe get access to the data? It's not worth to send it in for professional recovery, that's why I tried it myself in the first place.
Even if I messed up completely, I would still like to learn what was wrong with the drive. Anybody willing to help me diagnose the problem?
I figure there is nothing left to lose

Head resistances:
00D2, 010C, 00AD, 00DF.

Many thanks in advance!

Very likely your drive has entries on NRG list now, since you sent m0 translator command.
Check NRG list log in terminal by sending V40 command at level T
F3 T>V40

If you have 1 or more entries in V40 then this is a big trouble, but it might be possible to regenerate translator with professional tools.

P.S.
Above everythink you should first check heads contacts on pcb, clean them with a pencil eraser if they look dark. Oxidation could be a possible cause of all problems from the beginning, but cleaning it will not solve the damaged translator problem at this point.
Other possible cause are bad sectors on surface and/or weak heads.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

I cleaned the PCB contacts first before attempting any terminal commands, they were dull but cleaning them didn't help the drive anything. Still behaved the same.

It does have 11 entries ("B in hexadecimal") in V40 list, so the translator got messed up.
So we are for sure beyond the point of maybe being fixable without professional tools? Anything left to try? At this point I have nothing to lose as the data only has sentimental value, nothing I would spend money on.

Thank you!

You might try the Leonardo Method if you have only translator issue
http://www.hddoracle.com/viewtopic.php?f=6&t=196
http://www.hddoracle.com/viewtopic.php? ... 5&start=20
http://www.hddoracle.com/viewtopic.php?f=175&t=2281

but in my opinion there are further issues with your drive

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Can a translator-only issue result in a drive not becoming ready at all and repeated clicking of the heads? I mostly read postings of people who have limited access to the drive due to translator issues and can at least start to scan it with MHDD. I don't get my drive to be recognized most of the time, and if it does get recognized every once in a while it has size 0.

As I understand, the Leonardo method helps with a partial access problem, so I guess you are right and there are problems beyond the translator issue. I wonder if it is possible to check if the data area of the surface is readable via terminal. Any chance of trying to read a drive via terminal, or initiate some kind of surface scan via terminal, only to verify that the drive would even able to read any data?

So far, I have not seen any obvious error messages in the terminal whatsoever, also not when the drive is powered up "normal" and sitting there clicking away. Is there any way to find out where in the process of becoming ready it is getting stuck? Most of the time, people seem to get terminal error messages when a drive has problems becoming ready.

Thank you for any insights, I really like to analyse the problem further and learn, even if this drive is already beyond rescue for a hobbyist.

Wohooo! M100 got it going again, recognized every time now and I was able to start reading it with ddrescue. However, every few 100 MB it gets stuck and can't read the drive. I guess there might still be a chance to pull some photos off the drive? Learning as I go along...

No.
As i said, your drive might have further issues. The translator problem is only the consequence of the m0 given command.


Yep!


You might be able to read/clone surface in serial mode but only by using professional tools. However a lot of data will result as damaged due to sectors shift. Cloning in serial mode will be extremely slow, slower than a 56K modem, and can be possible only depending if other possible issues are not present.

I don't know if on a F3 architecture drive is possible to check if a specific sector is accessable via terminal commands, if is possible would be just for dignosis purpose.


One of the most used commands to use for diagnosis F3 drives in terminal is CTRL+X.
Send CTRL+Z command right after head calibration after powering on, then send CTRL+X and upload log in the forum, someone might understand which problem has your drive.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Sorry for my slow answers, but they still have to be approved. So, after the drive became accessible again after m100, I was able to grab about 5 GB via ddrescue (with some bad blocks), but hit a wall after that - no sectors readable beyond that. I guess now my wrong commands hit me . I got it right that I have to find out after which LBA I cannot read anymore and manually exclude that sector in the terminal via the instructions in your links, so the LBA->PBA translation fits again? Well, nothing to lose here and I am surprised that I actually got this far. Any recommendations on how to proceed, before I mess up things even more? Is there maybe a scripted software that would automate or analyse this process, available to mere mortals? No PC3000 or similar here, just "bare metal" and terminal access.

Some sources say that you can have the drive eliminate the bad LBA (after which I cannot read anything) itself by writing to it, so it puts it on the "bad list" by itself. Is that worth a shot as it is probably easier or will I mess up even more? Any experiences?

Thank you for all your hints and encouragement, I learned a lot so far! It's a steep learning curve, but I was already about to trash the drive, so any gain is a win, and if it is only for learning. I promise, I will never ever run m0 on a 7200.12 again

Well, as I fiddled again with the drive, I can add some more information:

I was able to find out the LBA after which no read is possible anymore. It is in this example 10130912 decimal, 0x9A95E0 which is slightly over 5 GB after the beginning of the drive.

However, using the commands



does not result in this address coming up in the V40 list, also not after a power cycle. Reading this address and beyond is still not possible.
This drive does have a whole bunch of bad sectors in those first 5 GB (after which reading is still possible), I guess that was the origin of the fault, maybe something got messed up when the drive was trying to reallocate all those sectors when it was still "sort of working". Lots of sectors also read slow.

Anyhow, lessons learned: Never mess up translation tables, ask, read and think a lot before blindly applying terminal commands . I am quite surprised that I still got the drive to go ready and even got a tiny bit of old photos off it, but seems like I shot myself in the foot. Love to go further, but I am probably lacking the experience to really tinker with all those different tables and have an idea of what I am doing. Probably the m100 command alone would have been sufficient to bring the disk back online and be able to maybe even read most of the disk, as I believe now.

I will keep fiddling with the drive as time allows me to. I have to figure out how to dump terminal outputs into a text file and I will be happy to provide logs if you still want to help me, but I see it more as a learning experience than a recovery from this point on.

Thanks a lot for your kind support!