Switch to full style
Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
Post a reply

RoseWood

February 22nd, 2018, 9:05

Hello
ST1000LM035
SBM3
1 TB
The drive in topic shows correct ID, capacity and FW then stuck in busy and no user area access.
Terminal output:
Boot 0x80M
QB
Rst 0x80MSrv DETCR init 0x0000
(P) SATA Reset

RAW OFF
PASS
(DOS Table) Worst Count: 000015F4 At SU: 00004888 NT: 0000000A OT: 0000000E
(POR) Recover Secondary MCMT Opened Recovered
(MC POR Duration): 0000000146
Send Status: COMRESET seen
CSpd= 6Gbps
Update Mask - 0000000006196520 - 00000008 - 00
Update Mask - 0000000006196528 - 00000008 - 00
Update Mask - 0000000006196530 - 00000008 - 00
Update Mask - 0000000006196538 - 00000008 - 00
Update Mask - 0000000006196540 - 00000008 - 00
Update Mask - 0000000006196548 - 00000008 - 00
Update Mask - 0000000006196550 - 00000008 - 00
Update Mask - 0000000006196558 - 00000008 - 00
Update Mask - 0000000006196560 - 00000008 - 00
Update Mask - 0000000006196568 - 00000008 - 00
Update Mask - 0000000006196570 - 00000008 - 00
Update Mask - 0000000006196670 - 00000008 - 00
Update Mask - 0000000006196678 - 00000008 - 00
Update Mask - 0000000006196680 - 00000008 - 00
Update Mask - 0000000006196688 - 00000008 - 00
Update Mask - 0000000006196690 - 00000008 - 00
Update Mask - 0000000006196698 - 00000008 - 00
Update Mask - 00000000061966A0 - 00000008 - 00
Update Mask - 00000000061966A8 - 00000008 - 00
Update Mask - 00000000061966B0 - 00000008 - 00
Update Mask - 00000000061966B8 - 00000008 - 00
Update Mask - 00000000061966C0 - 00000008 - 00
Update Mask - 00000000061966C8 - 00000008 - 00
Update Mask - 00000000061966D0 - 00000008 - 00
Update Mask - 00000000061966D8 - 00000008 - 00
Update Mask - 00000000061966E0 - 00000008 - 00
Update Mask - 00000000061966E8 - 00000008 - 00
Update Mask - 00000000061966F0 - 00000008 - 00
Update Mask - 00000000061966F8 - 00000008 - 00
Update Mask - 0000000006196700 - 00000008 - 00
Update Mask - 0000000006196708 - 00000008 - 00
Update Mask - 0000000006196710 - 00000008 - 00
Update Mask - 0000000006196718 - 00000008 - 00
Update Mask - 0000000006196720 - 00000008 - 00
Update Mask - 0000000006196728 - 00000008 - 00
Update Mask - 0000000006196730 - 00000008 - 00
Update Mask - 0000000006196738 - 00000008 - 00
Update Mask - 0000000006196740 - 00000008 - 00
Update Mask - 0000000006196748 - 00000008 - 00
Update Mask - 0000000006196750 - 00000008 - 00
Update Mask - 0000000006196758 - 00000008 - 00
Update Mask - 0000000006196760 - 00000008 - 00
Update Mask - 0000000006196768 - 00000008 - 00
Update Mask - 0000000006196770 - 00000008 - 00
Update Mask - 0000000006196778 - 00000008 - 00
Update Mask - 0000000006196780 - 00000008 - 00
Update Mask - 0000000006196788 - 00000008 - 00
Update Mask - 0000000006196790 - 00000008 - 00
Update Mask - 0000000006196798 - 00000008 - 00
Update Mask - 00000000061967A0 - 00000008 - 00
Update Mask - 00000000061967A8 - 00000008 - 00
Update Mask - 00000000061967B0 - 00000008 - 00
Update Mask - 00000000061967B8 - 00000008 - 00
Update Mask - 00000000061967C0 - 00000008 - 00
Update Mask - 00000000061967C8 - 00000008 - 00
Update Mask - 00000000061967D0 - 00000008 - 00
Update Mask - 00000000061967D8 - 00000008 - 00
Update Mask - 00000000061967E0 - 00000008 - 00
Update Mask - 00000000061967E8 - 00000008 - 00
Update Mask - 00000000061967F0 - 00000008 - 00
Update Mask - 00000000061967F8 - 00000008 - 00
Update Mask - 0000000006196800 - 00000008 - 00
Update Mask - 0000000006196808 - 00000008 - 00
Update Mask - 0000000006196810 - 00000008 - 00
Update Mask - 0000000006196818 - 00000008 - 00
Update Mask - 0000000006196820 - 00000008 - 00
Update Mask - 0000000006196828 - 00000008 - 00
Update Mask - 0000000006196830 - 00000008 - 00
Update Mask - 0000000006196838 - 00000008 - 00
Update Mask - 0000000006196840 - 00000008 - 00
Update Mask - 0000000006196848 - 00000008 - 00
Update Mask - 0000000006196850 - 00000008 - 00
Update Mask - 0000000006196858 - 00000008 - 00
Update Mask - 0000000006196860 - 00000008 - 00
Update Mask - 0000000006196868 - 00000008 - 00
Update Mask - 0000000006196870 - 00000008 - 00
Update Mask - 0000000006196878 - 00000008 - 00
Update Mask - 0000000006196880 - 00000008 - 00
Update Mask - 0000000006196888 - 00000008 - 00
Update Mask - 0000000006196890 - 00000008 - 00
Update Mask - 0000000006196898 - 00000008 - 00
Update Mask - 00000000061968A0 - 00000008 - 00
Update Mask - 00000000061968A8 - 00000008 - 00
Update Mask - 00000000061968B0 - 00000008 - 00
Update Mask - 00000000061968B8 - 00000008 - 00
Update Mask - 00000000061968C0 - 00000008 - 00
Update Mask - 0000000006196BE8 - 00000008 - 00ProcessRC: 00000000,00000000ReadContinuous: 00C32D7E,00000258TotalEntries:0000 XfrLen:0258UnrecovSectorCount:0000,0000NumUDEs: 00000000,00000000Failed: 40000087Out:
SP Regen FAIL
SPRegen [0000|43110081] @LBA=0x00C32D7EOut:
SP Regen FAIL
SPRegen [0000|43110081] @LBA=0x00C32D7EOut:

Any suggestions?
Thanks in advance for any help.

Re: RoseWood

February 23rd, 2018, 6:07

can you access terminal Level T> ?

Re: RoseWood recovery

February 23rd, 2018, 7:23

unknown wrote:ST1000LM035
The drive in topic shows correct ID, capacity and FW then stuck in busy and no user area access.
Terminal output: ...

Classic - MC has failed. Could be due to defects or drive's inability to write.
Another possible option is reading issues.

Unless there were improper recovery attempts, which made the situation worse (not uncommon with the cases like this), chances are high that the data is recoverable.

Re: RoseWood

February 23rd, 2018, 11:37

MindMergepk wrote:can you access terminal Level T> ?

Yes.

Re: RoseWood recovery

February 23rd, 2018, 11:38

Dmitri wrote:
unknown wrote:ST1000LM035
The drive in topic shows correct ID, capacity and FW then stuck in busy and no user area access.
Terminal output: ...

Classic - MC has failed. Could be due to defects or drive's inability to write.
Another possible option is reading issues.

Unless there were improper recovery attempts, which made the situation worse (not uncommon with the cases like this), chances are high that the data is recoverable.

Didn't do anything to the drive yet. :)
Still trying to diagnose the problem.

Re: RoseWood recovery

February 23rd, 2018, 11:48

unknown wrote:
Dmitri wrote:
unknown wrote:ST1000LM035
The drive in topic shows correct ID, capacity and FW then stuck in busy and no user area access.
Terminal output: ...

Classic - MC has failed. Could be due to defects or drive's inability to write.
Another possible option is reading issues.

Unless there were improper recovery attempts, which made the situation worse (not uncommon with the cases like this), chances are high that the data is recoverable.

Didn't do anything to the drive yet. :)
Still trying to diagnose the problem.


Well ,
Please make backup of imp sys files Before you start the show :mrgreen:

Re: RoseWood

February 23rd, 2018, 13:06

unknown wrote:
MindMergepk wrote:can you access terminal Level T> ?

Yes.


can help remotely if interested !

Re: RoseWood

February 27th, 2018, 7:54

I have backed up sys files and regen trans. The drive is stable now but with user area limit access to LBA 67000000.
tried to write back original translator but MRT doesn't support sys file/mods writing. :D

Any suggestions?
Thanks in advance

Re: RoseWood

February 27th, 2018, 13:15

unknown wrote:I have backed up sys files and regen trans.

awesome, you've done it

unknown wrote:Any suggestions?

you can throw the drive away, then take a hammer and break you fingers and never do DR again.

Re: RoseWood

February 27th, 2018, 13:25

Doomer wrote:
unknown wrote:I have backed up sys files and regen trans.

awesome, you've done it

unknown wrote:Any suggestions?

you can throw the drive away, then take a hammer and break you fingers and never do DR again.

:lol: :lol: :lol:
Awesome advice indeed.

Re: RoseWood

February 27th, 2018, 13:45

But I think 1 failed DR case out of 10 success DR cases per week isn't deserve to break my fingers. :D

Re: RoseWood

February 27th, 2018, 13:57

unknown wrote:But I think 1 failed DR case out of 10 success DR cases per week isn't deserve to break my fingers. :D


Ask the client whose data didn't get recovered . . .


:mrgreen:

Re: RoseWood

February 27th, 2018, 14:02

jono-ats wrote:
unknown wrote:But I think 1 failed DR case out of 10 success DR cases per week isn't deserve to break my fingers. :D


Ask the client whose data didn't get recovered . . .


:mrgreen:

Until I backed up resources and recovery process didn't end yet, then the question can't be asked yet. :)

Re: RoseWood

February 27th, 2018, 14:24

If you have backups, not all is lost.

Maybe we need to add to the usual instructions to backup modules first, the important part that is to know if one´s firmware tool can *write* those modules back.

Do you have another fw tool to try writing the modules back ?

Is it possible to write it back through terminal, even if it is to mean a lot of manual work ?

Re: RoseWood

February 27th, 2018, 14:43

rogfanther wrote:If you have backups, not all is lost.

Maybe we need to add to the usual instructions to backup modules first, the important part that is to know if one´s firmware tool can *write* those modules back.

Do you have another fw tool to try writing the modules back ?

Is it possible to write it back through terminal, even if it is to mean a lot of manual work ?

A friend of mine has PC3K UDMA. We will try to write original resources back.
Thanks for reply :)

Re: RoseWood

February 27th, 2018, 19:11

(Patch ROM
Send handshake to access SA
Access SA and read backup of file 3_028_0
Next, run translator regeneration
Repower HDD and send handshake again
now try sector edit - if first and last LBA can be read, then you can recover now.

If last LBA cannot read, then write original 3_028_0 to module 2B in modules table)
This advice has given to me from a reputable member of this forum (all old members knows him perfectly )
So, I didn't recklessly regenerate translator before I took the advice to.

Re: RoseWood

February 27th, 2018, 19:50

Spildit wrote:
For this drive he would need ATA vendor specific commands in "Indirect Mode" (have more options then the "regular" ATA VSC to write sysfiles. I don't think MRT will work to write those sysfiles back.



That´s why I said that maybe it is interesting to add to the usual recommendations for backing up modules to be sure that said modules can be written back, as a module that cannot be sent back to the hdd wouldn´t be much useful ..... Like, before changing things, make a backup and try to rewrite some not-important module back to the drive to see it the tool works.

Re: RoseWood

February 28th, 2018, 0:03

Spildit wrote:ATA vendor specific commands in "Indirect Mode" (have more options then the "regular" ATA VSC to write sysfiles. I don't think MRT will work to write those sysfiles back.

You state as if you knew the way "indirect" mode works in pc3k :) Rosewood drives can NOT write sysfiles(FIDs). ATA modules CAN be written. The trick is made by pc3k to "deceive" a drive so that it thinks it writes a module but in fact it writes what we need.

Re: RoseWood

February 28th, 2018, 23:28

Did another idea emerged in your mind but "sniffing"? How about just ask developers how it works?

Re: RoseWood

March 1st, 2018, 6:39

@ Doomer
Unfortunately, I will continue doing data recovery. :mrgreen:

Case solved
Special thanks to my friend Tawfeek_Mokhtar. :good:
Attachments
e1e rosewood.jpg
Post a reply