ST4000VX005 (SkyHawk)

[fzabkar]

How can two drives die at the same time with the same firmware fault? :-?

Are you able to dump the SA before they go offline?

Can you retrieve a SMART report?

I expect that the following error is due to the absence of the "DaT" blocks (which you cleared).

SCRAM NVC is lost!

[unknown]

How can two drives die at the same time with the same firmware fault?

They are both in the same QNAP enclosure (RAID 1) and this still very weird.

Are you able to dump the SA before they go offline?

I managed to unlock by MRT and I could get a full backup of sysfiles.

Can you retrieve a SMART report?

Yeah sure, I will post it ASAP.

I expect that the following error is due to the absence of the "DaT" blocks (which you cleared).

After this message appears I could only read 10 MB from UA. Then the drive stuck in busy and repeat this :
Boot 0x0100MVM0148CV10
SpinUp
TCC:001F

Trans
Rst 0x0100MVM0148CV10
SAdd:0x0055A3C5
NVCScram Saved HB Size:020A
LD: MD_Alloc:00000078 HB_Alloc:0000 MD_Alloc:80380000 HB_Alloc:8032 FlashRestore MD_Saved:00000078 HB_Saved:00000000 MD_CRC:0154
PP: MD_Alloc:0000B400 HB_Alloc:0000 FlashRestore
PVTSize: 00002C00 CompSize: 0000008C DeCompSize: 00002C00 MD_Saved:0000008C HB_Saved:00000000 MD_CRC:8183
WCD: MD_Alloc:00012000 HB_Alloc:02E6
FlashRestore............................................................................................................................................................................
Failed power-on replay: 0x0052

[unknown]

SMART values returns zero's:
Num Flgs normlzd worst raw
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000001
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000
0 0000 0 0 00000000000000

[unknown]

Solved.
All customer data backed up.
Thanks a lot Mr. Franc for trying to help.
Many many thanks to Mr. Pepe.
He did it in approximately 10 minutes.

[pepe]

, it looked like it was 10 minutes but it took some hours to figure out things before i was able to make it
interesting stuff...

[fzabkar]

Did you notice the QNAP logs? (not related to data recovery)

[unknown]

Did you notice the QNAP logs? (not related to data recovery)

I received the two drives without the enclosure.

[pepe]

yeah, perhaps they did not die simultaneously.
were the dates OK on the one you recovered?

[fzabkar]

Solved.
All customer data backed up.
Thanks a lot Mr. Franc for trying to help.
Many many thanks to Mr. Pepe.
He did it in approximately 10 minutes.

It's too bad that the solution disappeared under a cone of silence and secret handshakes.

I suspect that the simple fix was to clear the NvCache in the Extra_Space.

I believe the following thread is a similar problem with a similar resolution, but the OP gave up too soon:

https://forum.hddguru.com/viewtopic.php?p=310254#p310254

In the present case, I expect that changing the "NvC" header (Non-volatile Cache) to "CvN" may be all that is required. Or you could fill the entire area from off 0x180000 to 0x1FFFFF with 0xFF.

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00180000  58 4E 76 43 E6 D1 34 09 42 44 46 00 00 00 00 00  .NvC.............
00180010  00 00 00 00 3F 00 87 43 00 00 00 00 00 00 00 00
00180020  04 00 00 00 10 00 00 00 0A 02 02 04 58 00 00 02
00180030  98 24 01 04 B8 D8 01 01 00 00 00 00 00 00 00 00
00180040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00180050  00 00 00 00 00 00 00 00

You could also clear the CElog.

Change the following from ...

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00159000  20 C0 3F 00 FF FF FF FF AD DA AD DA FF FF FF FF   À?.ÿÿÿÿ.Ú.Úÿÿÿÿ
00159010  14 20 19 12 7C 00 00 00 7C 00 20 33 2E 32 2E 30  . ..|...|. 3.2.0
00159020  2E 30 20 00 FF FF FF FF FF FF FF FF FF FF FF FF  .0 .ÿÿÿÿÿÿÿÿÿÿÿÿ
00159030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00159040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00159050  FF FF FF FF FF FF FF FF 48 D1 34 09 42 44 46 00  ÿÿÿÿÿÿÿÿHÑ4.BDF.
00159060  10 90 01 00 E2 A7 00 00 BD 00 00 00 00 00 48 00  ....â§..½.....H.

... to ...

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00159000  20 C0 3F 00 FF FF FF FF FF FF FF FF FF FF FF FF
00159010  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
........
00159060  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

[pepe]

I suspect that the simple fix was to clear the NvCache in the Extra_Space.

no it wasn't that simple.

[fzabkar]

It's too bad that the solution disappeared under a cone of silence and secret handshakes.

I suspect that the simple fix was to clear the NvCache in the Extra_Space.

I think this is the solution:

https://www.hardmaster.info/articles/20-09-2023.html

To solve the [NVCFormatCorrupt] problem, it is necessary to clear the ROM code block describing unfinished transactions, and the easiest way to do this is to insert the required part, read from a working similar disk, into the patient's ROM, since transaction logs do not affect the basic CS, and a simple "zeroing", such as writing the FFh pattern, will not help here. After making the necessary edits, the disk "comes to its senses" and you can read data from it normally.

I think this means that one only needs to patch the patient ROM with the NVC areas from a donor ROM.

[msnirvana]

The Extra_Space is located at offset 0x15A000 in the ROM.

This is the structure as I see it.

Code:

before clearing Extra_Space

0x6000 - 0x25FFF  firmware data or user data?
0x26000 -         firmware data?
0x38488           small DaT block
0x438B8           small DaT block
0x46400 -         user data

Code:

after clearing Extra_Space + power-on

0x6000 - 0x25FFF  empty
0x26000 -         firmware data?
0x38488           small DaT block
0x438B8           small DaT block
0x46400 -         empty

The "firmware data" at offset 0x26000 contains the following text:

Code:

HT_Med_Rd_Unconn_FillBufferDone - Unrec Pre-Read Error
HT_Med_Rd_Unconn_FillBufferDone - Unrec Error
Need to add support for disc errors?

Need to add support for DiscErrorDetected()
Need to add support for DiscErrorRecoveryDone()

do you know were is located smart data?

[fzabkar]

do you know were is located smart data?

on the platters

[msnirvana]

do you know were is located smart data?

on the platters

i mean at offset mr.bean

[SWM]

fzabkar, don't pay attention. I wanted to answer at first, but something told me not to get involved.

[msnirvana]

fzabkar, don't pay attention. I wanted to answer at first, but something told me not to get involved.

Do you think the thing that told you not to get involved could be Satan?

[fzabkar]

Do you think the thing that told you not to get involved could be Satan?

@msnirvana, I have already answered your question. The SMART data are on the platters, not in ROM.

Why are you trying to fake the health condition of a faulty drive? That's not a "repair".

https://forum.hddguru.com/viewtopic.php?p=318331#p318331

i have couple of these hdds for repair. they are tested and working very well, how can i solve this problem with gas sensor?

[msnirvana]

Do you think the thing that told you not to get involved could be Satan?

@msnirvana, I have already answered your question. The SMART data are on the platters, not in ROM.

Why are you trying to fake the health condition of a faulty drive? That's not a "repair".

https://forum.hddguru.com/viewtopic.php?p=318331#p318331

i have couple of these hdds for repair. they are tested and working very well, how can i solve this problem with gas sensor?

After working with dozens of EXOS hard drives, it has been proven to me that some of them report this error unrealistically. This is a factory bug, and there is a problem in the sensor system and its related circuitry.