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

[igen]

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

For what ?

What will it give me?
The donor I have (see photo above at the beginning of the post and compare with patient) is a twin...

[Lardman]

Other than the fact you're essentially using the clients drive to do research on

To confirm the donor heads you are using actually still work and that they can be swapped between drives. 1 faulty and 1 working does not give you the combinations required to prove anything is working correctly.

At it's simplest level, you've put a set of donor heads in a drive which don't work, confirming they still work in the original donor would be my first step and then that they will work in another drive.

We've all had heads which should work but just don't.

[igen]

Other than the fact you're essentially using the clients drive to do research on

To confirm the donor heads you are using actually still work and that they can be swapped between drives. 1 faulty and 1 working does not give you the combinations required to prove anything is working correctly.

At it's simplest level, you've put a set of donor heads in a drive which don't work, confirming they still work in the original donor would be my first step and then that they will work in another drive.

We've all had heads which should work but just don't.

Lardman

I want you to understand me well...

It's not a matter of heads (compatibility or efficiency)...
It's just that the arm with the heads does not leave the ramp.
And this is only with the original bios of the patient - with the bios of the donor - it does it ...

[fzabkar]

This is my take on the situation:

Code:

donor HDA   + donor PCB   + donor ROM   + patient heads -> spin up, ID, seek, no data access
patient HDA + patient PCB + patient ROM + donor heads   -> spin up, beep, no seek
patient HDA + donor PCB   + donor ROM   + donor heads   -> spin up, ID, seek, no data access
patient HDA + patient PCB + donor ROM   + donor heads   -> spin up, ID, seek, no data access

For some reason, the patient ROM doesn't get along with the donor heads.

[Lardman]

This is my take on the situation:

Code:

donor HDA   + donor PCB   + donor ROM   + patient heads -> spin up, ID, seek, no data access
patient HDA + patient PCB + patient ROM + donor heads   -> spin up, beep, no seek
patient HDA + donor PCB   + donor ROM   + donor heads   -> spin up, ID, seek, no data access
patient HDA + patient PCB + donor ROM   + donor heads   -> spin up, ID, seek, no data access

For some reason, the patient ROM doesn't get along with the donor heads.

Or the donor heads are now damaged and this is the result.

Code:

donor HDA   + donor PCB   + donor ROM   + DONOR heads -> spin up, ID, seek, no data access

[igen]

This is my take on the situation:

Code:

donor HDA   + donor PCB   + donor ROM   + patient heads -> spin up, ID, seek, no data access
patient HDA + patient PCB + patient ROM + donor heads   -> spin up, beep, no seek
patient HDA + donor PCB   + donor ROM   + donor heads   -> spin up, ID, seek, no data access
patient HDA + patient PCB + donor ROM   + donor heads   -> spin up, ID, seek, no data access

For some reason, the patient ROM doesn't get along with the donor heads.

Or the donor heads are now damaged and this is the result.

Code:

donor HDA   + donor PCB   + donor ROM   + DONOR heads -> spin up, ID, seek, no data access

Fzabkar,

If the donor heads were damaged (which is theoretically possible, e.g. a broken tape during change the heads or some other damage, e.g. electrostatic), they would behave in the same way with the donor's bios (the same "beep").
And this is not the case - Hdd trying to calibrate with the donor's bios.

----------------------------------------------------
During the exchange I checked:
Patient surfaces without any damage.
Patient heads - clean as a tear - no trace of contact with the plates.

The replacement of the heads went smoothly - without any errors or problems.

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

I would simplify it - no PCB - because I checked it in all possible ways - PCB is meaningless.
Given that the donor positioner does not work with the patient's rom - I would not consider platers either

During the exchange I checked:
Patient surfaces without any damage.
Patient heads - clean as a tear - no trace of contact with the plates.


donor HDA + donor ROM + patient heads -> spin up, seek, ID, no data access (as expected, because at least one of the patient's heads is not working - preamp channel?)...
donor HDA + patient ROM + patient heads -> spin up, seek, no ID, no data access
patient HDA + patient ROM + donor heads -> spin up, beep, no seek
patient HDA + donor ROM + donor heads -> spin up, seek, no ID, no data access

Considering that in the production process of the same batch of disks (twin disks) all elements are the same - it is impossible for them to differ at the production level and to be differentiated as to the differentiation of individual components.

Yes - in the post-production process (of the same batch of discs) - PLlists, serial numbers, adapters are differentiated and determined ... but not different heads or their preamplifiers. The supplier delivers them all the same (of course - as part of delivery to the same production batch).

Therefore, I believe that this is clearly a problem between the bios and the head.
And the changes - that the disk automatically made to the FW at the time of failure.

Last edited by igen on February 14th, 2023, 13:04, edited 2 times in total.

[fzabkar]

These are the differences I found with Winmerge:

Code:

Compare CPs_00 with CPs_01

Filename,Folder,Comparison result

0081_GNRC.bin,,Binary files are different
0083_MINQ.bin,,Binary files are different
0084_FCHN.bin,,Binary files are different
0087_FSVS.bin,,Binary files are different
0088_FAEP.bin,,Binary files are different
0089_FIMG.bin,,Binary files are different
008A_FCRD.bin,,Binary files are different
0095_EPOD.bin,,Binary files are different
0099_HIN1.bin,,Binary files are different
009A_HIN2.bin,,Binary files are different
009C_FLLG.bin,,Binary files are different

FSVS is an adaptive module. Some components are identical, but most are different.

Code:

Filename,Folder,Comparison result

FSVS_ACDC.bin,,Binary files are identical
FSVS_CYL.bin,,Binary files are different
FSVS_FLTS.bin,,Binary files are identical
FSVS_KT.bin,,Binary files are different
FSVS_MACT.bin,,Binary files are different
FSVS_MAFF.bin,,Binary files are identical
FSVS_MFGF.bin,,Binary files are identical
FSVS_PES.bin,,Binary files are different
FSVS_RRDC.bin,,Binary files are identical
FSVS_RRO2.bin,,Binary files are different
FSVS_RW32.bin,,Binary files are different
FSVS_RWGP.bin,,Binary files are different
FSVS_RWTC.bin,,Binary files are identical
FSVS_SWTG.bin,,Binary files are different
FSVS_TPCR.bin,,Binary files are different
FSVS_WIND.bin,,Binary files are different

[igen]

Fzabkar,

I've attached the diff file (from winhex).

Report of differences value hex.txt

(188.07 KiB) Downloaded 447 times

If you can take a look.
Two things stand out.

1). Considering that they are twin drives, the structure of their roms should be similar. i.e. there may be differences in the values of individual addresses, but when you look at the structure as a whole, there should be no structural differences.

While browsing both roms - such significant differences I noticed.
Because I focused on values such as "00" or "FF" (I'm looking for a flag, switch) I noticed that from the address E0400 (the whole rom) and from the address E1400 there are large groups of FF values in the donor rom - while in the patient's rom there are any data ....

2). Looking for single differences (in the address space of small groups) I noticed single byte differences:

...............Patient....Donor
CA00C:.......0B..........40
CA0BC:.......35..........00

Maybe it's some any flags in HIN1 , 2... ?

[fzabkar]

I don't know what the EPOD module does. HIN1 and HIN2 look like information modules of some kind.

If you are convinced that the problem is in the ROM, I could try to patch a donor "CP" into your patient ROM to see whether this changes the behaviour. We only have 11 choices ...

[fzabkar]

EPOD appears to consist of 0x200-byte blocks, each of which is subdivided into two 0x100-byte blocks. Some blocks are empty (filled with 0xFF). I suspect that this module may be modified during the operation of the drive.

[igen]

I think so.

Of course, I could be wrong, but...
Logic indicates that this is not a problem with the heads (in the sense of their compatibility or whether they are operational).

Anyway, this is the first time I encounter such a situation.
The article about Rebuild Assist got me thinking.

I had a few, a dozen or so cases when disks (HGST, Hitachi) had damaged heads and it manifested itself in the fact, that only the motor was accelerating in the disk - and after nothing else was happening.
But here - after replacing the bios - the disk is trying to calibrate.

So logic indicates that there is a problem on te line : the bios line and head electronics ...

Thank you in advance for your help.
If it's not a problem for you then try to help me, please.

P.S. I'm a little worried about these FF areas in the donor bios...
Perhaps this is the "something extra more" written in the patient's bios...

[fzabkar]

Sorry, I can't patch the ROM. There is a table of modules (ID 0x81) whose 96-bit hash needs to be recalculated. Unfortunately I don't know the algorithm.

[igen]

Okay, thanks for trying.
I appreciate it.

All I have to do is put the heads back on.
For the clarity and possible confirmation of my opinion.
I'll let you know - what the results will....

[igen]

Hello,

As promised - I'm writing back.

I swapped the heads back again - patient to donor and donor to patient.

Unfortunately - the situation is the same as at the beginning.

The donor works properly - with its original heads.
And the patient (on his original heads) began to calibrate again - but just like at the beginning - he does not read any sectors....

[Lardman]

Time to try another donor.

[drHDD]

Time to try another donor.

I don't think it will help. Drive makes writing test as part of init and if it fails you will not get access to UA. I didn't see that donor heads finished writing test successfully yet. So if you get re-calibration, id and can't read UA - this is result of writing test fail.

[fzabkar]

This experiment suggests that we only need to recalculate the checksum of each module, not its original 96-bit hash:

https://www.hddoracle.com/viewtopic.php?p=23475#p23475