Serious issue with SSHD ST4000DX001, UART 3.3v or 1.8v

[wmelting]

Hello,

My colleagues were using 10 ST4000DX001 SSHD in a ZFS pool and two of these drives failed almost simultaneosly and we were unable to save the RAID array. I was looking into using the serial interface to try to get into some insight and maybe with the help of someone local, we could get this drive back on the array.

So, does anyone know what's the voltage level of the UART (3.3v or 1.8v)?

Best regards

[fzabkar]

Probably 1.8V, but measure the voltages at the header to be sure.

[wmelting]

Ok, now I know it's 3.3v, i've reached the terminal and now the output is this

Rst 0x40MRead Retry was needed to recover data

---SOC PSM Command History---
Cmd#/PsmCmd Clump Offset Length LbaMid LbaLow LbaBits39To32 Options Status DestClump DestOffset
0000 0198 0049 0000 8000 0819 0000 C000 0018 C207 38DA

0B00 0198 0040 0009 8000 0810 0000 C000 0018 C207 38DA

0A00 0164 0000 0008 8000 175A 0000 C000 0080 C207 38DA

0900 0071 0000 0800 8000 0000 0080 C000 0080 C207 38DA

0801 01E0 06D0 0010 0000 0000 0000 C000 0080 C207 38DA

SIM Error 101F LBA 0000000000000000 FD 08423093
RW Error 00000000
Table Recovery Faked and Completed

No Phy: Staggered spin bypass

Request spin / disc table recovery
Spin issued

TCC:0014

RECOV Servo Op=0900 Resp=0005
LED:000000BC FAddr:00008004
Rst 0x40M
LED:000000BC FAddr:00008004
LED:000000BC FAddr:00008004
LED:000000BC FAddr:00008004
LED:000000BC FAddr:00008004

I'll be trying to crunch the most information I can this night, but can anyone tell me what i'm looking into now? I see the SOC PSM Command History table, is this about relocated sectors?

Regards

[Dmitri]

i've reached the terminal and now the output is this

The output you're getting suggests that the drive sees servo labels, but unable to read the SA.
This could be both a NAND issue and drive's inability to read the SA from the platters.

How you're getting this output? Do you have the original PCB installed?

JFYI, you can't just swap the PCBs on these drives, even if you'll move the ROM, it won't help. Unless you have a considerable experience with such drives, chances are very high to make the situation worse.

[wmelting]

Currently I don't know if the original PCB is installed. I know the EEPROM matches with the chassis, but not the PCB. I might have found someone here in Portugal, but because the data is spanned thru various disks I would have to ship the whole server (it has 12 disks).

[mr_spokk]

Contact José at: https://www.datarecoverylab.pt He can help you out.

[wmelting]

Ok thanks, we eventually contacted a lab in Guarda and are awaiting for the results.

[pclab]

Working on it

[fzabkar]

@pclab, can you measure the voltages at the TTL header?

[pclab]

Imaging hehheh

Attachments

[pcimage]

What was the issue?

[pclab]

First was a messed up ROM swap eheheheh
After getting the right one, got a good PCB, solved FW problem and voilá.

But to get things good: at 55% of imaging, the destination HDD for (provided by the client) also failled. Guess what: another Seagate

Got to get another drive and start all over.