Request for feedback (opinion) - for the newer HGST drive...

[igen]

I got an HDD drive, brand HGST, model: HUS726060ALE614 with a capacity of 6 TB.
The good side - it is a conventional (no helium) disk.
The bad side - this is a drive that is not supported by PC3K...

The disk is detected correctly (ID, capacity, FW, etc.).
Unfortunately, there is no access to the data area - ABR error ....

Because PC3K does not support this family of drives - I have no way for deeper diagnosis of this case (SA and others) ...
I don't know what the Tech Key is for this family. PC3K detects it as the ARIES-KP family.
Based on the interview with the client, the drive was not exposed to any impact (mechanical) factors...
Except - there was a moment when someone else had it and used it for several hours.

The disk "died" slowly - over several days. First errors appeared, then problems with copying - and finally it "died" ...
So it rather indicates - that some slight "impact" factor has occurred...

After the first "inspection" - something about the boot sound of this drive made me disturbing...

I asked the customer if he had another, the same disk.
Fortunately, he confirmed ... This drive was bought together with several others - the same.
The same twin disc was delivered to me.

Photo of the front of the patient and donor below (patient and donor - front.jpg).

Photo of the back (PCB) of the patient and donor below (patient and donor - PCB's.jpg).

PCB photo:

Probably ROM chip (1 MB):

I compared the "sound" (acoustic) starts of both disks - and there are some differences.

ATTENTION !!! You have to turn the volume up to max!!!
In the "sound" recording below, I show the start of a healthy (donor disk) and patient - for compare it:

compare sound starting HDD patient and donor.ZIP

(2.57 MiB) Downloaded 151 times

I did notice a difference - for comparison - the start of the damaged patient disk (from about 11-12 seconds there is a change and "other - more" clicking of the heads):

Also when running in Universal Utility there are differences:
To illustrate, i show the start of a healthy disk (donor) in Universal Utils:

And - for compare - this is, what it looks like when trying to start Universal Utility patient disc - after powering up and trying to start right away:

As a curiosity - i will mention the fact - that the "patient" disk after starting (for several dozen minutes - every few - several seconds) something "cracking"...
As if it was trying to read something ...
After this time (several tens of minutes) - these sounds is stop and when i try to enter the Universal Utils - shows messages with fewer errors:

--------------------------------
IN SUM.....
--------------------------------


I haven't opened the drives yet.
I don't know how many heads it has and what condition the surface is in.

But - my experience tells me there are probably two options:

1). Damage to at least one of the heads (except the system one) - and the disk does not load the translator.
2). The Heads are good - but the translation modules are broken... This is the worse option (because without the ability to edit SA I can't do anything else)...
But in this case (nr 2) the question arises - would it show the correct capacity of 6 TB in the ID ?

---------------------------------

ASKING FOR ADVICE...
---------------------------------

My question is as follows:
Is there anything else I can check before replacing the heads ?

Thanks for the answer.
Regards, Igen.

[igen]

Theoretically I can read the ROM and extract the NVRAM... But will disabling the heads help me?
Will disabling the inoperative (defective) heads will load the translator and will confirm the damage of the heads - while confirming the efficiency of the translation modules ?
I need data from all surfaces (Long "heavy" AV files)....
Is there a tool to check, edit and correct the checksums in the ROM of this model?

[fzabkar]

Let us know if you find the "NVRAM". (I have written a tool to parse these new ROMs.)

[igen]

Hello again - Fzabkar...
Long time we no talk....

Will you share your knowledge about this tool for NV-RAM editing ?

For several days I've been trying to figure (research and development) - how to get to the service data of this family (ARIES-KP) - i.e. address data of Techno-Key, SA and others...

P.S.

As a curiosity....
I will give you the fact that in 2011...
I moved the heads and platters from a 5-platter disk (1 TB) with similar symptoms. But - then I had access to the disk's SA - replacing the PCB (the same FW version and after the "transplant" of the small NV-RAM chip) led to a change of the switch (2 bytes) in the NV-RAM - and as a result, it was impossible to restart the disk ....
ACELab for me then helped - swapped these two bytes and the disk started...

Luckily - i got 100% of my data back then - but... nnfortunately, my further research (related to the address position of these two bytes) came to nothing in other families...

Regards
Igen

Regards
Igen

[igen]

I have the (irresistible) impression that ACE - many "know how" is not shared.
Another issue is whether he (consciously) doesn't want to - or just doesn't know it...

Analyzing the history (and i've been in the DR market for a while - over 20 years - and I follow most cases and what's going on) - i'm starting to think that most of the research is a bit "amateur" - based on what some amateurs (sometimes semi-professionals) will discover and explore - on the market....
And i wouldn't be surprised at all if it turned out that "great" solutions - which are implemented by ACE or HRT in their products - are ideas, solutions and results of research by individual people from the USA, Russia, Ukrainian, Canada, China and other countries...
As proof, i will give an example of problems with the "famous" Seagate 7200.11 series of drives and their problems with SMART and translator....
Before ACE introduced this trivial data access solution (in these cases) - a few - a dozen or so people (or companies) - for 1-2 years reaped unimaginable benefits from it ...
I remember that the average price - then - for data recovery (from such locked disk - and it was enough to short-circuit the reading channel, clear the smart, clear a-list and recalculate the translator - in a "one" word - 2-3 min.) was about 5K USD....

Igen

[igen]

I am now analyzing the case with the formatted ST2000LM007 (Rosewood - AF version).
I'm comparing the contents of the MCMT and the RAM dump (there's a piece that looks like part of the MCMT).
When I get the answer and the results of the research - i will publish it

Igen

[fzabkar]

There is no "NVRAM" in the traditional sense.

Here are my tools (HROMchkx and hgstfwcpx):

http://users.on.net/~fzabkar/FreeBasic_W32/Hitachi/

My "research":

https://www.hddoracle.com/viewtopic.php?f=21&t=2549

[igen]

In atach: two rom's - patient and donor

Attachments

rom's patient and donors .ZIP

(1.08 MiB) Downloaded 156 times

[fzabkar]

I have extracted all the modules.

Attachments

HUS726060ALE614.7z

(486.78 KiB) Downloaded 158 times

[igen]

Great thanks....
I will see that in monday.
Now i end the work...

Regards.
Igen

[igen]

I changed heads...

And... the next problem...
I swapped the heads between the drives (donor to patient) and (patient to donor).

The donor disk starts normally, i.e. with the heads from the patient it behaves like a patient (before replacing the heads).
Normal detection and no sector reading....

But the patient - something very strange is happening.
The engine starts up - and - the normal shouldbe the heads (positioner) go above over the plates....

But I hear - that the warheads don't come off the ramp....!!!
There's just a quiet "tick" and that's it.
The platters are spinning, but there are no heads above the platters...

What the hell is going on?

[igen]

Rebuild Assist....

Fuc.... sh.... !!!

[fzabkar]

What happens if you swap the heads and PCBs?

[igen]

After replacing the heads - the donor disk (with the patient's heads) behaves like the patient before the transplant. The plates spin up, the head is calibrated, full ID and capacity are obtained - but I do not have access to the data sectors (ABR).
And this situation - in my opinion is ok - ie it is in line with expectations.

On the other hand, the patient (with working heads from the donor) - the motor spins up, reaches the nominal speed and I only hear something - a one short "beep" - as if the positioner does not go over the working area of the plates ....

This symptom does not occur when I connect the rom from the donor to the patient (on any electronics - doesn't matter), - i.e. then the patient tries to work with the heads.
Of course - for obvious reasons - the disk has no chance to start with another rom.

Everything indicates that the patient disk - at the time of failure heads - changed something in the rom (SA?) and now expects damaged heads...

I found something like this - and unfortunately it explains such bizarre behavior:
https://forum.hddguru.com/viewtopic.php ... 5&start=40

If this is flagged in any way in the rom - then there are chances. If in SA - it's basically GAME OVER (in the absence of any SA editing tools)

[fzabkar]

The FSVS ROM module contains adaptive parameters, ie those which are unique to each drive.

ROM module FSVG appears to contain parameters which are family related.

VS = specific variables ?
VG = general variables ?

[Lardman]

Everything indicates that the patient disk - at the time of failure heads - changed something in the rom (SA?) and now expects damaged heads...

That doesn't track - otherwise your donor drive would now be in the same state as the patient.

[igen]

From what I hear, the head does not try to calibrate. So adaptives don't really have anything to do with it.
Head incompatibility? The discs are very twinned. So that's out too....
And if even - then how to extract and edit these VS and VG parameters?
Sorry, but I'm not strong in hex...

[igen]

Everything indicates that the patient disk - at the time of failure heads - changed something in the rom (SA?) and now expects damaged heads...

That doesn't track - otherwise your donor drive would now be in the same state as the patient.

Very likely.
But to check it, I would have to move the heads back - then some issues would be clarified ...
But I don't want to do that for obvious reasons...

[fzabkar]

Each module has a 96-bit hash. I don't know how to recompute this.

[Lardman]

I'd say you really need a second known good donor.