i have a 2,5'' (mariner family) with corrupted (on both copy + composite too) of module 01 (DIR)
but the others 407 modules was read fine.

found on database module 01, but the drive does not allow to write on any copy of SA that module:
Module 01 writing error Device Error Detected: "DISK SERVO WRT FLT AI SSM TIMEOUT ERROR"

so i went into plan "B", hot swap.

since i do not have a matching drive with matching fw and rom version, i wanted to write on that donor, from database, all modules and rom.

fistly i wrote by ID the module 01(DIR).
then i try to write others modules, by utility greturn me:

Module 11 writing error; unexpected error: HDD Requirs 506 sectors. Program sends 495

(same for some others modules)

So i went into ABA writing, and it was fine, but after writing ROM and modules ROM into pcb, the drive does not ID, only kernel mode.

any ?

Were the heads maps the same?

Did you try writing service tracks?

_________________
http://www.datasaversllc.com

yes HM is same 0.1.2.3!

What tool are you using? If you are working with SD WD HD DR it will never read mod 01 for you. Not very often does this mod read or save for some unknown readson. Sometime I can get it to read by loading in slow read mode the HDD when you first access the HDD. Did you try and download the new WD Program for this one too?

On UDMA this is not a problem. Also what is wrong with this HDD. Normally if mod 01 is bad this does not effect the data on the HDD and you can get off data. What are you trying to do?

_________________
Iorana Haraharaini

hi i have both tools.
anyway, the hard drive was falled down, other DR company judged it unrecovereable after try headswap.

i try too swap heads and hdd was not autorecognize itself, but with another donor i try hot-swap and i was able to read all fw modules. but opening modules i noticed that part of module 01 have "ªUªUªUªUªUªUªUªU" filling (from the half of itself till the end) that module is necessary to autoboot the drive, is the Dir module.
anyway for curiosity i attached that module here.

There is nothing wrong with that module. The 0xAA55 pattern is just padding.

ISTM that rewriting the MOD directory with one from another drive is potentially a very bad thing to do. MOD 01 contains a table of MODs that lists each MOD ID together with its size in sectors.

For example, here is the entry for MOD 11:

12 02 11 00 EE 01 03 18 90 00 95 30 03 00 95 30 03 00

The data are in little endian format. The MOD size is 0x1EE sectors, ie 494.

Each MOD entry occupies 18 bytes (0x12) and appears to begin with 0x1202 (or 0x0212 if endianness is taken into account).

The last entry begins with 0x5502, although this does not appear to be consistent.

The total number of MODs is stored at offset 0x30. In your case it is 0x01F8, ie 504.

_________________
A backup a day keeps DR away.

@ fzabkar

from your analyze i gathered useful info.

but honestly i must disagreee about the padding.In my experience when i get modules like that, is always related to weak heads/SA demage.

i changed heads once again on this drive, and now i read all that module 01.
i attach here, it looks a bit different from previous posted.

1) all part of the module is read now.
2) @ offset 0x30 there is a different value! i checked the modules readed by hot-swap, they are 401 so agree with the new value (400)

The size of MOD 11 in the table is now 0x01EF, ie 495.

Are you saying that the contents of MOD 01 changed as a direct consequence of a head swap? Seems very strange to me ...

_________________
A backup a day keeps DR away.

yes, i confirm that i swapped head and posted the new module 01 read with new heads.

i can see @ offset 0x0030: 91 01 (should be 401 in decimal)

When I suggested that the trailing data pattern was only padding, I should instead have said that I don't have a clue as to what it means. Sorry.

I have since examined one other MOD 01 image and I see that the size of its trailing data block is relatively small when compared with the size of its MOD table. Your trailing data blocks are disproportionately large by comparison.

I also notice that the last entry in the aforementioned MOD table begins with 0xFF02, whereas yours begin with 0x5502 and 0xAA02.

I would have expected that the entries in the table would point to the physical location of each MOD in the SA, but I can't recognise any data structure that would fit this hypothesis.

_________________
A backup a day keeps DR away.

Upon further examination I suspect that the trailing data may indeed be irrelevant. I'm now suggesting that, when the MOD directory is generated, the data are written to an area of RAM whose contents are random. It appears to me that these contents are not initialised to a known state before the MOD table is written.

All entries begin with 0x1202 except for the last one. The first byte of the last entry appears to retain whatever value was present in RAM. This would explain why I saw 0xFF02 in the case where the trailing bytes were all 0xFF, and why in your two cases the values are 0x5502 and 0xAA02.

_________________
A backup a day keeps DR away.

I have extracted the MOD table data in little endian word format and then sorted each record according to column 6.

It appears that the MOD table contains the starting sector of each MOD. The format is LBA rather than CHS. Perhaps the two identical columns correspond to each copy of the MOD???

_________________
A backup a day keeps DR away.