ST1000LM024 - S-list issue or incompatible heads?

[cheadledatarecovery]

Patient HDD came in clicking with failed heads:
ST1000LM024
REV C
First two characters of PN: E7

Donor heads used from:
ST1000LM024
REV A
First two characters of PN: E7

Two sets of donor heads have been used from matching donor drives (both Rev A). Results are replicated.

With current donor, pre-amp is good enough match for HDD to spin up. Reading data from the SA or LBA is slow going, with significant read errors, in particular the S-list). The SA can only be saved error free when when the number of read-retries in "Utility Status" is increased from default of 102 to 255.

However, the issues is that the translator function is not fully working. Data in LBA 0 is incorrect. What would be typical data in other significant LBA values is also incorrect (e.g. 2048). I'm aware that the Samsung uses a dynamic translator and requires reading the S-list fully and for the heads to be able write data. Tests show that it is not possible to write data to the HDD, either to LBA values or to the SA. When I change any Hex values either in SA or LBA the changes appear to save when 'refresh' command is sent, however, when HDD is powered off-on the changes are no longer present.

It is possible to read good data via RAW recovery on LBA. Some areas of the HDD read OK (25+ Mb/s), some areas are very bad, and the read capability is not head specific (good and bad areas on all heads).

I am unsure whether the results will be improved by finding a "Revision C" version of this drive. Hopefully the reason why it is not possible to write to the drive is part incompatibility. We are currently looking for this drive ( viewtopic.php?f=15&t=31705 ). But the Rev C is less common and we would prefer a supplier within the EU.

Can anyone think of any other tests to rule out before trying to find a Rev C drive?

Thanks,
John

Terminal output:

ActiveFW : 00
FWVer : 0001
SATA PLL cal done
DDR size detected = 16MB

DDR size detected = 16MB

*PAUNI_L2958*PA VID=0011 PN=000D Rev=0001- PA_LSI2958 Found
*PAUNI_L2958*PA VID=0011 PN=000D Rev=0001- PA_LSI2958 FoundU
S_0SO_1
SPU@23C,5060mV
IS=3
CLA ..36/65
HO..OK
HO RPM=3263 OK
AC 780
ST..Skip..OK
mS1 00000003
GT:406
SC(L):4100/16
BE.N:28
LD..OK
SK C: 7747 H:0
Loaded FIT ( 0: 0: 1)
CalibTable Loaded. Rev:0x1B
ResoTable Loaded. Rev:0x01
Bump Limit Loaded. Rev:0x01
RRO1xTable Loaded. Rev:0x01
Fw Active 00
Ovly loaded to 0x00014D00
Ovly loaded to 0x1002DF60
FdtTable Loaded. Rev:0x02
| 17 | SLIST | 4 | 0 | 0 | 5B04 |
| 17 | SLIST | 4 | 1 | 0 | 1140 |
| 17 | SLIST | 4 | 2 | 0 | 1140 |
Unknown file id 384
Up MC

PwrOn RRO1x @ H0
Table) cos = -711680, sin = 496640
Coeff) cos = -35792, sin = 50008

DiskSlip : 122 [SrvTrk]
DiskSlip : 131 [SrvTrk]
0. phs diff 1 [wedges] Table) 155, coef) 154

PwrOn RRO1x @ H2
Table) cos = -716544, sin = 489472
Coeff) cos = -30592, sin = 34175

DiskSlip : 122 [SrvTrk]
DiskSlip : 129 [SrvTrk]
4. phs diff 0 [wedges] Table) 156, coef) 156
TgtCyl: 832
Hd: 2 Zn: 0 Avg.:- 229
TgtCyl: 263568
Hd: 2 Zn: 1 Avg.: 1045

SVCAL(0080,0000)-->PASS
RecordValid Fail : 0406E47D 0007E41D
ENG>| 152 | ZONHEAL3 | 64 | 0 | 0 | 5B04 |
[INIT_ATWH_V2 REV:0008 GRP:1]
RdyTm = 15764986 us
EPOK
mS1 00000003
SK C:155464 H:0
SC(U)..4100/80
UD..OK : 80
PK_4 C: 9 H:0

healing Enable 003C 001E 0000 001E

[jermy]

what's the full PN form patient & donor (uploading the sticker from both of them from the front, will be best) ?

[Izualim]

Hello, what exactly happened to the drive?

[chinopk]

Heads are compatible enough, if you can read SA error free, why not try hot swap load translator from donor and check can you find the correct data at relevant sectors ... just a thought. never encounter a translator problem with these drives

[cheadledatarecovery]

This job came in via an IT Support company, so unsure how the end user has treated the HDD. Most likely physical shock.

Please find attached an image of the patient and the two donor HDDs used.

I will try smart hotwap and see what happens.

I have this job raised with AceLabs tech, but they suggest the failure of the translator is due to incompatible heads.

John

[Doomer]

| 17 | SLIST | 4 | 0 | 0 | 5B04 | <-- SList rear error 5B04
| 17 | SLIST | 4 | 1 | 0 | 1140 | <-- Slist read error 1140
| 17 | SLIST | 4 | 2 | 0 | 1140 | <-- Slist read error 1140

[Dmitri]

It is clearly visible that drive did not load the S-list and in that case translator can't function properly.

According to the description, most likely the primary issue is surface defects both in the SA and user area. If so, it will be necessary to reassemble the SA manually first.

We have worked with such drives before and if my assumption is correct, it gives no reason to expect for this job to go like some WD recovery.

[cheadledatarecovery]

Hi Doomer & Dmitri

Yes I'd spotted the S-List errors in terminal. I had attempted to relocate the S-List module to a different cylinder and then use the rebuild S-List command. However, any changes made in the FIT editor are not saved when the drive is powered off/on. Would the drive not being able to read the S-List completely prevent writing data to either the SA sectors or the LBA areas?

It has been possible to save a working version of the S-List and other modules but it was necessary to increase the number of read-retries in "Utility Status" from default of 102 to 255. Before this it was not possible to read all of the modules on any head. There is a full saved copy of the SA now. However, each time the drive is powered on it reports the errors in S-List and the drive does not initialise correctly.

At this stage I am try to determine whether it is worth while trying to find a "REV C" version of the donor, on the basis that the donor parts used so far (see above) are not quite a good enough match. However, given the way the drive performs when reading LBA values (highly degraded) it is entirely possible that the SA sectors are degraded and improvements will not be made with other donor parts.

I will try a SMART hotswap later today using the saved SA and post the results.

Thank you for your feedback so far.

[cheadledatarecovery]

A smart hotswap was completed copying all but the M and B Overlays. The patient drive gets to ready and the translator function appears to be normal. Sector 0 is now full of “00” however it is possible to find the correct start of the partition and the MFT. The MFT has been partially read, and when files are extracted they are working.

The drive is very unstable. And produces a lot of messages in terminal (see below). The customer has a large number of files on the HDD so it will be difficult.
Thanks for all the suggestions from the forum members.

Terminal output whilst reading:

S_2 0000013E 00000141 0000013E 00000000
S_2 0000013E 00000141 0000013E 00000000rb(e1140 3 2 0 290)
rb(e1140 3 2 0 290)
rb(e1140 3 2 0 290)
W-MC e(00001140) ( 3: 2: 0:0x09:0x0013)
Successful writeRList
[GL][SAVE]
[GL][RS:05 0012BB768 90E25000]
.
[GL][TP:00012BB768][E:1140]
[GL][ADD:0012BB768][C:0005][E:1140]
.
[GL][0012BB768->626]
[GL][0012BB768->626]
.
[GL][0012BB768->626]
[GL][0012BB768->626]
[GL][TP:00012BB768][E:0000]
[GL][0012BB768->626]

S_2 0000013E 00000141 0000013E 00000000rb(e1140 3 2 0 290)
rb(e1140 3 2 0 290)
rb(e1140 3 2 0 290)
W-MC e(00001140) ( 3: 2: 0:0x09:0x0013)
Successful writeRList
[GL][SAVE]
[ESAT_ER:00000010|00275F02|00002458]
[ESAT_ER:00000010|00275F02|008B24D0]
[PRTC_ER:0080|00B24D0]
@
[RESET:2 0002139D:0008FDD1:5F070027]
rb(e1140 37 1 0 171)
rb(e1140 37 1 0 171)
rb(e1140 37 1 0 171)
rb(e1140 37 2 0 171)
rb(e1140 37 2 0 171)
rb(e1140 37 2 0 171)
W-MC e(00001140) (37: 2: 0:0x0B:0x00A7)
rb(e1140 37 1 0 171)
rb(e1140 37 1 0 171)
rb(e1140 37 1 0 171)
rb(e1140 37 2 0 171)
rb(e1140 37 2 0 171)
rb(e1140 37 2 0 171)
W-MC e(00001140) (37: 2: 0:0x0B:0x00A7)
rb(e1140 63 1 0 641)
rb(e1140 63 1 0 641)
rb(e1140 63 1 0 641)
W-MC e(00001140) (63: 1: 0:0x0A:0x0098)
mS1 00000003
SK C:156473 H:0
SC(U)..4149/134
UD..OK : 134
PK_4 C: 35 H:0

[chinopk]

glad you have manage to solve this.
thanks for sharing

[cheadledatarecovery]

This recovery is still on going. The critical documents have been recovered, but imaging the drive is very slow. Occasionally the drive will get to BSY and not return to RDY, requiring power off, and then hotswap to get back to RDY with reading LBA. I've tried most settings to try an improve reliability on read (reverse, single sector access, look ahead off, PIO etc.) but it does not make a difference. Fortunately the donor heads are stable and are not degrading. I think just a lot of patience is required on this job.

Thank you for the previous suggestions, the customer's critical data has been recovered.

When in BSY the terminal output sends constant output of:

ADD:00CD823D0][C:0005][E:1140]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][RS:05 00CD823D0 90D4A000]
.
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]
[GL][00CD823D0->3FA]

etc. etc.

[pepe]

I usually apply some fw patches to avoid glist adds and prevent writing to SA. I am not sure what features PC3k has currently as i do it my way. There are a lot of configuration variables, but unfortunately none of them seems to be directly affecting relocation.

[Dmitri]

Would the drive not being able to read the S-List completely prevent writing data to either the SA sectors or the LBA areas?

Logically - yes, by design. Physically - no, but here a lot depends on the software used.
SA access / operation doesn't depend on the availability of user modules / user lists.

The drive is very unstable...

It's performing remaps in the background.


And there are two overlays only - main and burn :)

[cheadledatarecovery]

All finished on this job now - it was possible to get the HDD stable enough to extract the majority of the critical documents and the 6GB PST file.

Thanks for your suggestions.

John

[data-medics]

Well done, that's a job a lot of guys would have written off as a lost cause. Every now and then perseverance like this pays off. The rest of the time we just waste three days trying and failing.