Seagate ST9320423ASG 0LBA problem

[sector0]

Dear Gurus,

first of all I would like to say that this is an awesome site, especially if someone is totally frustrated
searching the way to solve the problem with the hard drive.

I will try to be very short, my problem:

On one of my laptops has the 2,5" hard drive seagate ST9320423ASG.
One day, suddenly, this hard drive became inaccessible.

At boot-time, in BIOS-Setup, this drive could be recognized with a size of 0MB.
MHDD recognises this HD also with 0 LBA error.

All Data on this driva are very important for me and there is no possibility to outsource to a DR-professional.

After searching in Internet and also on this forum it was clear for me,
that there could be something with SA-area and computer doesn't know how to deal with it.

My first guess was: weak head(s) or not readable parts of SA-area.
I have replaced heads through other ones from the good donor of the same model. - 0LBA problem remains.

OK, what next? Internet is a very good source for Information:
there are some cases describing the solution of 0LBA Problem,
but they affect only this specific hard disk model (Seagate 7200.11).

I decided to try this way with a help of selfmade device (discussed here: http://www.mapleleafmountain.com/seagatebrick.html).

After successful setup, the first try was the most described way:

CTRL-Z
F3 T>

Now go to level one
F3 2>/1

And give the S.M.A.R.T. erase command
F3 1>N1

disconnect the SATA power cable from the drive and wait one minute.
Then plug the SATA power cable back into the drive.
CTRL-Z
F3 T>m0,2,2,0,0,0,0,22

Max Wr Retries = 00, Max Rd Retries = 00, Max ECC T-Level = 14, Max Certify Rewrite Retries = 00C8
User Partition Format Successful - Elapsed Time 0 mins 00 secs

No effect, 0LBA problem remains without change.

Next try, with deleting G-List and reset translator.

CTRL-Z
F3 T>i4,1,22

disconnect the SATA power cable from the drive and wait one minute.
Then plug the SATA power cable back into the drive.

CTRL-Z
F3 T>m0,6,2,,,,,22

After this step there was a wonder! On SATA interface there was a rather long time ~20 sec
but BIOS could recognize the drive with 320GB. Ok, I thought I was near the solution, at least I was on the right way...
MHDD also could see 320 GB, I started the test... there was a lot of sectors with read/write error.
Ok, after this test I pluged this drive into the Windows-PC, long pause during the boot, the drive could be recognized... but with
2 raw partitions. No filesystem, no files at all.... I thought may be now the drive is in the state known as "BSY error"?

Ok, I thought the correct action would be F3 T>m0,2,2,0,0,0,0,22 again.... I have done that (, and now
the drive has 0LBA error again. I have tryed all combinations of the terminal commands... nothing helped me,
0LBA error could not be corrected.

Dear all, I know now that 0LBA is not a problem this is only a symptom of the problem.
But what are the ways to find out what is the reason of this 0LBA-symptom?
Could somebody point me to the right path in order to find a solution and to get access to my data?

Thanks in advance.

[pcimage]

Drive has translator issue and will only access LBA up to certain point, due to "extra" defects added during final tests at the factory.

There are generally solutions for this but not DIY I'm afraid. Specialist knowledge is required.

[sector0]

Dear pcimage, thank you for reply.

What do you mean saing ""extra" defects added during final tests at the factory" ?

What is "DIY"?, sorry for my incompetence....

Thanks

[dmarques]

Hi,

DIY is do it yourself.
So what he means is that it's an issue that it's possible to recover, but with some manual labour and not an easy solution, as translator was regenerated not taking into account all that it was supposed.
It's a question that you can only understand if you have experience with seagate defect lists.

[sector0]

Ok, I see... is it possible, using the terminal commands, to check and to confirm that this is really a translator problem and not some other problems?

Thanks in advance!

[dmarques]

You can check the commands to check heads for example, and you'll see that they are just fine probably.

[sector0]

Ok, I checked all heads and it seems they are ok:

Rst 0x10M
ASCII Diag mode

F3 T>/2

F3 2>H0
Hd 0

F3 2>H1
Hd 1

F3 2>H2
Hd 2

What I do not understand in this context is: why recalculation of translator worked only one time? All attempts to recalculate it again had no effect...

I have tried an other test, on the language of terminal commands it is: OddEvenEncroachmentTest. May be some one can help me to interpret results of this test for 3 heads:

F3 T>T0,8,0
Head 0 ECC threshold A
L Cyl perfct OTF <=4 >4 Unreadable
0 62C 134 0 3 0
1 668 F6 0 0 5 <------ this, I think, is not OK, but what it means?
2 68F D4 0 0 0
3 63F 124 0 0 0
4 678 EB 0 0 0
5 684 DF 0 0 0
6 616 14D 0 0 0
7 638 12B 0 0 0
8 692 D1 0 0 0

F3 T>T0,8,1
Head 1 ECC threshold A
L Cyl perfct OTF <=4 >4 Unreadable
0 773 F 0 0 0
1 76E 14 0 0 0
2 771 11 0 0 0
3 77A 8 0 0 0
4 774 E 0 0 0
5 773 F 0 0 0
6 777 B 0 0 0
7 76E 14 0 0 0
8 775 D 0 0 0

F3 T>T0,8,2
Head 2 ECC threshold A
L Cyl perfct OTF <=4 >4 Unreadable
0 745 1E 0 0 0
1 744 1F 0 0 0
2 741 22 0 0 0
3 73F 24 0 0 0
4 746 1D 0 0 0
5 749 1A 0 0 0
6 744 1F 0 0 0
7 74E 15 0 0 0
8 742 21 0 0 0

Thanks in advance!

[dmarques]

Hi,

It worked only one time, because it did not take into account a certain area that it should.

[sector0]

dmarques thank you for your reply!

Ok, if the whole problem depends on this certain area, which obviously should be read in order to get information about the real amount of LBAs, then, I think, there are two possibilities:
1. this area is (always) readable 2. this area is (always) not accessible and/or not readable.

Therefore I am some sort amazed to see, that at the beginning (one time) this area was readable (or accessible) and after that this area is not readable/accessible anymore.

Am I wrong in my logic?

[dmarques]

One thing I do not understand.
You say that one time this was readable? When does that area was readable?

[sector0]

Dear dmarques,

in my first post I tried to explain the situation... May be my explanation was not clear enough...

In short form: after the first try with recalculation of translator (m0,6,2,,,,,22) the size of drive was 320GB and visible by BIOS and by MHDD.

After the next try (with m0,2,2,0,0,0,0,22) I see again: 0LBA instead of 320GB.

Several attempts to recalculate the translator again (with m0,6,2,,,,,22).... no success at all.

Thanks for helping me!

[dmarques]

But when you got the first time the full size, you got access to LBA, right?

To full LBA or just parcial?

[sector0]

Yes, the drive could be recognized by BIOS, although with rather long pause, and the vsisble size was 320GB exactly as it should be. The model Nr.: ST9320423ASG shows this size also. MHDD recognized this size as well and I could start the nondestructive test on it.

But after m0,2,2,0,0,0,0,22 I got again 0LBA and nothing helped me untiill now to change this state.

[hddguy]

But after m0,2,2,0,0,0,0,22 I got again 0LBA and nothing helped me untiill now to change this state.

The more you write to the SA unsuccessfully the higher the risk of causing some serious problems.

I think this case is beyond your capabilities now.

You should close the job or outsource to someone who can handle it for you.

[sector0]

Dear hddguy,

thanks for your comments. I really appreciate your point of view...
But outsourcing unfortunately is not an alternative for me...

You are absolutely right saying that the more unsuccessful attempts to write to SA are done, the more unpredictable can be the end result. Sure, statistically I agree with you, but we are talking about general IT-features. If a bit is set to 1 (after successful write operation) it should remain 1 untill the next time it will be rewritten.

So, in my case it seems that a bit is successfully set to 1, but effective it is still has 0 value...

Some tries with m0,2,2,0,0,0,0,22 and/or with m0,6,2,,,,,22 indeed resulted in not successful end-result. Ok, but if the next time I got "successful formatted" it would mean, all things which should be written were correctly written without any error. Or there is something I am missing?

Any help will be really appraciated.

[hddguy]

What do you mean saing ""extra" defects added during final tests at the factory" ?

Additional defects identified during additional testing at the factory are not taken into account with the standard 'm0' command. You have cleared this list of additional defects so they are now included during rebuilding of translator. when translator is rebuilt it only rebuilds up until the first defect is encountered then stops hence limited accessibility.

Ok, but if the next time I got "successful formatted" it would mean, all things which should be written were correctly written without any error

you should also note the time it takes to complete, probably will be 0 seconds.

Here as 0LBA is persistent I think it is likely there could be other problems here, but assuming you are able to repair this you will very likely be presented with a partial translator and limited access to data.

But outsourcing unfortunately is not an alternative for me...

Unfortunately I think is your only alternative.

[sector0]

Additional defects identified during additional testing at the factory are not taken into account with the standard 'm0' command. You have cleared this list of additional defects so they are now included during rebuilding of translator. when translator is rebuilt it only rebuilds up until the first defect is encountered then stops hence limited accessibility.

Ok, agree... But why after the first time m0,6,2,,,,,22 I could see the full capasity 320GB? Following your logic, even after the first m0,6,2,,,,,22 the 0LBA problem should remain, right?

you should also note the time it takes to complete, probably will be 0 seconds.

This is true after each m0 command I saw "0 seconds"

Here as 0LBA is persistent I think it is likely there could be other problems here

That is exactly what I think: there is not (or not only) translator problems, but most probably some other problems which I try to identify. It is sometimes easy to say "you should better outsource..." but if I still dont know what is the cause of this problem (0LBA), it is not possible to claim that only other pro-people are able to repair the drive. I think the better diagnosis is still needed, before we can be clear what it is better to do as next step.

Still any help is highly appreciated!

[hddguy]

it is not possible to claim that only other pro-people are able to repair the drive. I think the better diagnosis is still needed, before we can be clear what it is better to do as next step.

At some point nobody was able to repair this. But pros have the time, money, resources and fundamental understandings of basic HDD operations. some firms have committed research departments who spend each day researching the most complex if failures. This is where solutions are developed.

I appreciate your eagerness to learn and support it, but ultimately this is somebody elses data you are taking risks with. If you do not have the facilities/resources to research this problem properley for yourself then you shouldreally consider outsourcing it to someone who can do it.

Just my opinion,

[Nick_CT]

I agree with hddguy that although you have done some good research and are on the right track in certain aspects, but the more you fiddle with this drive the more complex it will become to finally recover it. New version of professional equipment has almost a one click solution for this kind of problem if I understand the problem correctly, as I did a drive with a similar issue last week. If you need the data back you really do need to send it to someone with the right knowledge and equipment.

[dmarques]

Right now I think it's a case of how much the data really worths, if it's yours or not also should be taken into consideration.