Hello,
i've this drive and i need data, when i power on heads do click like crazy and it stay in busy state.
I was able to clone about 25% of surface with hotswap from good donor drive, but now i'm stuck because there are a lot of bad sector in surface and when heads hit them DE is not able to jump those (drive goes busy and heads start again to click as before i did hotswap).
Unfurtunally i can't send hardware reset command in DE or even re-power the drive after read error due to hotswap condition (hotswap hundreds of time after every reading error is not an option), also soft reset and fast jump on bads don't help on surface portion that i've still to clone (drive starts again to click immediately after heads hit bads sectors).

I think problem is that FW is trying to automatically reallocate bad sectors, but is not capable to do that so it goes crazy.
Do you guys know a way how to disable automatic reallocation on this samsung drives as we do on WD drive (by editing mod 02) or Seagate drive (by editing sys 91 or by sending congen commands) ?

Also, i think S-list (mod 11) and D-list (mod 29) are corrupted on this drive but i don't know how to fix them. I think that could be another cause of this problem.
Can someone help me please?

I upload patient drive resource so that you might give a look to those modules, thank you
http://www.mediafire.com/file/ax18d6zl2 ... 826358.rar

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

All modules and tracks are physically ok, but if you open S-list and D-list of this drive with an hex editor, then you will notice that are full of data.
If you compare these modules with those of a healthy donor, you will notice that donor's S and D list have many patterns with 00 and FF.

Does someone of you able to help me to fix S and D list, please?

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Your RLIST (13h) and TLIST (12h) also look wrong.

If you could upload modules 11, 12, 13, 29, and 02 (FIT) from your donor, I could try to work out the structure of the modules.

BTW, when you say "hotswap", do mean "smart hotswap"?

_________________
A backup a day keeps DR away.

Hi Frank,
yes i mean smart hotswap as written on AceLab forum:
http://forum.acelaboratory.com/viewtopi ... ng+hotswap

Here, i post all fw resource of donor drive:
http://www.mediafire.com/file/f8vfi2bsa ... 818444.rar

i hope that you can help me

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

That Ace thread describes a "smart hotswap". That is, the patient's critical modules are transferred to the donor's MC, and then the donor is restarted so that its PCB inherits the patient's defect lists, etc. If you had used an ordinary hotswap and then attempted to image the patient, the patient would have inherited the donor's defects when it tried to update the respective modules, ie after the first reallocation.

I verified that the FIT modules had identical directories, so I would think that this eliminates the possibility that the defects could have been written to the wrong CHS locations.

This is how I believe the donor's SLIST is structured:


The data are little-endian.

There appears to be a limit of 21760 (= 0x1FE00 / 6) defects. Also, there is a copy of this defect list at offset 0x20000, and a second copy at 0x40000.

The defects in your patient's SLIST seem to be restricted to head 0, and the defect list is full, but not corrupt.


If you wish to clear (?) the SLIST, then you would ...

fill the range from 0 to 0x1FDFF with 0xFF
fill the range from 0x1FE00 to 0x1FFFF with 0x00
copy 0 - 0x1FFFF to 0x20000 - 0x3FFFF and to 0x40000 - 0x5FFFF

_________________
A backup a day keeps DR away.

I thought that S-list was damaged because when in Sediv i push the button for S-list defects show on patient drive, it returns me error.
I get same error also when i push the button for T-list defects show.
Probably it's software bug that is not able to open correctly defects list when are too much.



What can you say about T-list?
Does it really appear corrupted in your opinion?

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

I'm examining the other modules now. I'll post my analysis as soon as I have something. BTW, I see that the DLIST has a single copy at offset 0x1FE00. It is also full.

_________________
A backup a day keeps DR away.

The DLIST has a 10-byte header. Your donor has 0x1762 records whereas your patient has 0x9B93. Each record has a length of 0xA bytes.


The data area is the range from 0x0A to 0x1FDFF. There is a copy of the DLIST at 0x1FE00. Empty records are padded with 0x00. There is no third copy as there is in the SLIST module.


If we cut off the header, the data look like this:


Since the DLIST records occupy the range from 0xA to 0x1FDFF, then it can accommodate a maximum of 0x32FF records.

(0x1fe00 - 0xa) / 0xa = 0x32FF

The header of your patient's DLIST is reporting 0x9B93 records, ie a size of 0x613C8.

(0xa x 0x9b93) + 0xa = 0x613C8

Therefore the DLIST has overflowed its allotted space, ie it is corrupt.


AISI, if you wish to clear (?) the DLIST, then you would fill it with 0x00 and write two headers, the first at 0x0 and the second at 0x1FE00

_________________
A backup a day keeps DR away.

I think I was wrong about the TLIST. It looks OK.

_________________
A backup a day keeps DR away.

I think I was also wrong about the RLIST. It looks OK. The reason I suspected this module is that it has no header.

_________________
A backup a day keeps DR away.

The TLIST module appears to consist of a header and two data regions. The remainder of the module is filled with 0x00.

Here is your donor:

header


region #1


region #2


If we carve out these regions, they look like the following:

region #1 (6 heads)


I don't know why, but the pattern looks better if we cut the first word. It seems to be related to the number of heads in some way.

region #1 (after cutting first word)


region #2

The size of region #2 is determined from the header, ie ...

0x6 x 0x60 = 0x240

In your patient's case the size is ...

0x6 x 0x1D5 = 0xAFE

_________________
A backup a day keeps DR away.

I'm not sure that I have determined the CHS associations in the SLIST and DLIST correctly. Something doesn't look right. Regardless, the SLIST is still OK and the DLIST is still corrupt.

_________________
A backup a day keeps DR away.

Isn't the SLIST the primary defect list? If so, then you shouldn't touch it unless it is damaged. Moreover, the drive should never write to it.

_________________
A backup a day keeps DR away.

Thank you Frank, i will do some research and see if i can continue cloning the drive.


Yes, S-list is like P-list for seagate, sometimes as p-list it can get damaged due to new entries when there are bad sectors on surface.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Did you or someone else move the G-list to the P-list? This would explain why the SLIST is full.

_________________
A backup a day keeps DR away.

Your RLIST module has several sections. I have made some guesses as to their structure. (The donor's RLIST is empty, so I have no proper comparison.)

RLIST -- 0 - 0x3FFF

0x1140 = uncorrectable read error
0x1301 = unknown error code ?
Attr = attributes

RLIST -- 0x4000 - 0x41FF


The following section of the module looks like "noise". The last 0x200 bytes are a copy of the first 0x200. The data are incompressible using WinRAR.

RLIST -- 0x4200 - 0x43FF


RLIST -- 0x4400 - 0x45FF

_________________
A backup a day keeps DR away.

No Frank, i didn't.
I know that G to P list (or R to S list) can lead to bad data recovery operation, so i never do that.
I don't know what customer has did to this drive and if he sent it to some other DR company before me.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

After long time, i decided to reply to this thread to let all you know that i solved this case last year by using SHT.
With SHT i was able to do smart hotswap and then dump S and D list from factory copy on surface 2 and overwrite them on SA-0. MRT and Sediv don't have any option for SA-2 modules backup (only from SA-0 and SA-1), SHT fortunatelly can do that.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Thank you Spildit, your suggestions are always very good

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Sorry for bumping an old thread but it seemed really relevant:
I have a HD501LJ that had bad contact with its PCB due to oxidation.
The bad sectors count grew to 30MB, thanks to someone at Badcaps I found a way to clear that with chkdsk.
However the defect list stayed intact according to the drive checked via a TTL interface.
So the performance is bad since the drive has to seek for these defective sectors.
Is there any way to clear the growth defect list?