I have parsed your MOD table and have attached a list of SA MODs and their sizes in sectors. The total number of MODs in SA is 0x143 (323).

I have also attached the VSC key files for each MOD. The MOD IDs are in little endian format.

In my first draft for the MHDD script, I have left the sector count at 1 for those MODs that have 256 sectors or more. I'll wait for your feedback before I decide how to handle them.

In the following modified test script, I have changed the value of the count register from $80 to $00, with the expectation that it will read 256 sectors rather than 0. Hopefully it won't lead to any catastrophic errors if it doesn't work as expected. It's your call whether you think it is safe to do. Afterwards you would need to concatenate the 128KB and 64KB segments, and then compare them against your previously retrieved 192KB ROM image.

_________________
A backup a day keeps DR away.

The script above worked the same as before. I guess the $0 works! So for Western Digital, $FF=255 and $0=256. Great.

And I managed to try out your long....long script. I am afraid that it needed to be split up, or otherwise MHDD crashes. I am guessing that MHDD parses the script and gives each line a line number when it first starts it... if there is a buffer overflow, MHDD ungracefully exits without even trying to run the script. Anyway, I split it up into 4 script files.

I also hacked your script to use a different input and output directory rather than the MHDD directory for everything.

Here is an example of my hacks:

And as I said, the huge file you sent was split into 4 files... I am not sure how many lines of code it takes to crash MHDD, but I think it is a little over 1100 lines.

And then there was the errors I got. Something went wrong with two MOD files. 34 and 32 both gave me errors and the script stopped running. By commenting them out, everything else ran fine. These were the problem sections:

This was somewhere near the middle or end of my first of 4 "allmod" files. So to summarize, here are the edits I made to your MHDD_SCR.TXT file:

1. Spit it into 4 parts, keeping the reset and the magic Vendor Specific Code at the top of each
2. Made every input be sucked in from the modkeys subdirectory (which I created in DOS as I unzipped the MODkeys.zip file there)
3. Made all output go to "out" subdirectory, which I created in DOS prior to running MHDD
4. Removed two sections that caused errors on my hard disk.
5. Added my notes to the top of each file

So I am the proud owner of a ZIP file of 325 BIN files that I dumped... but I guess you said we skipped the large MODs? I thought you said 323 files? Anyway, I am attaching the resulting file here.

The total number of SA MODs is 323. Your ZIP archive has 321 MODs (323 MODs less MODs 32 and 34). You have included a TXT file plus three 3ROMn.BIN files in the count.

I didn't actually skip the large MODs. I only retrieved the first sector of each. I have now attached a script to handle the large MODs. The CONCAT.TXT file needs to renamed as CONCAT.BAT. You need to run this batch in order to concatenate the MOD segments.

_________________
A backup a day keeps DR away.

I found that MOD 32 is the RBBLIST (Relocated Bad Block List) and MOD 34 is the G-list (Grown Defect List).

See http://www.salvationdata.com/data-recov ... rive02.htm

The example is for a Black I drive, not ROYL, but my research suggests that the IDs for these two modules are the same in both series.

Corruption of these two MODs appears to be a very common problem. In fact it's so common that the solution involves only a few mouse clicks with the appropriate tool.

Google turns up several hits on the subject:
http://www.google.com/search?q=%22RBBLI ... %22royl%22

http://www.google.com/search?q=wd+OR+%2 ... ddguru.com

BTW, I believe that the reason that MOD 4F is missing from the ROM is that it doesn't appear in the SA.

Also, when you retrieve MOD 109, I suggest you compare it against your PCB ROM image. The MOD should have a 512-byte header, after which the contents should be identical until near the end.

More on MODs 32 and 34 ...

Could you rerun the MHDD script just for those two MODs and restrict the sector count to 1? If this works, then try incrementing the count until it fails.

MOD 34 has a size of $0C, and MOD 32 has a size of $08.

_________________
A backup a day keeps DR away.

Your SMART data appear to be stored in MOD 21 at offset 0x2F9E. Each attribute appears to occupy 12 bytes.

column 1 = attribute ID
column 4 = current normalised value, 0xC8 = 200, 0x64 = 100
column 5 = worst normalised value
columns 6,7 = raw value (little endian) ?


It would appear that your drive is reporting zero against the Reallocated Sectors Count, but it has hit the threshold for Reported Uncorrectable Errors and Hardware ECC Recovered. There also appear to be 17 (?) Command Timeouts.

MOD 26 contains the text strings "DLGDIAG" and "5.04f", so it would appear that you have run WD's Data LifeGuard diagnostic against the drive.

_________________
A backup a day keeps DR away.

Interesting thing you found out about the MOD 32 and MOD 34. You know, I wonder what those files look like on the good drive? I presume that at some point I will read that drive, but I have to go pull it out of a server to do any (hopefully nondestructive) tests on it.

I notice that you seem to have read the SMART data table in its raw form. I have seen the same table essentially using a lot of different drive utilities (including WD diagnostics). I don't know what to make of the E7 FF FF FF for "Reported Uncorrectable Errors" but I would imagine that this represents the fact that every normal attempt to read data from the drive generates an ECC error code or that sets the ATA error flag. I don't know if that aspect is significant.

A7 E5 05 0A 00 00 00 "Hardware ECC Recovered" seems to be rather high. I think I have noticed this while viewing SMART data table before, but I haven't thought it exactly the clue I was hoping to find. Maybe it tells something about the drive circuitry or platter read heads failing? I will see if I can dig up a SMART data report in text format. Oh, and by the way, the Wikipedia says that unless you know what Western Digital is thinking for this parameter's raw value, then ignore it. See http://en.wikipedia.org/wiki/S.M.A.R.T.#Known_ATA_S.M.A.R.T._attributes. In other words, this raw value could be broken into bytes or words or bits that each mean something, and the decimal equivalent may not matter.

But as you may know, both have something to do with ECC stored on the drive's platters. In a normally operating drive, an ECC error typically means the drive's platters have a problem or the read heads have a problem, etc. But I guess what we are hoping is that something is corrupted, and the above massive error rates are false flags?

Here is my big mods for my bad drive. I concatenated them.

Again, I did some editing to your script to place things in a subdirectory. The same thing with the batch file... I put them all in a subdirectory so I could zip it. Putting all the input and output files in one basket gets messy. Here is my batch file and of course the big bad mods!

When I reduced the sector count to $01 for mod 32 and 34, the same error occurs in the same place when I run the script. "ERROR: Drive reports error" This error occurs after it read Line 1 through Line 8. So there is nothing to show for these mods unless you know how to read them from the alternate platter?

But I do have some S.M.A.R.T. Logs from MHDD. I noted that MHDD reports the wrong serial number when it reads the SMART data, although it gets it correct in other parts of its logging. Anyway, I have the same log for both the BAD and GOOD disks. Quite a few differences.

THANKS SO MUCH for your help, fzabkar.

Your SMART data are very interesting. The first thing I notice is that neither drive has any reallocated or pending sectors. This would suggest that MOD 34 (G-List) should be identical for both drives, but that's only my speculation. I don't know how this would impact on the RBBLIST (MOD 32), though.

The next thing that strikes me is that the ATA SMART command retrieves only 17 attributes out of the 21 attributes that are stored in MOD 21.

Those not reported are ...

Reported Uncorrectable Errors
Command Timeout
Temperature Difference from 100
Hardware ECC Recovered

Coincidentally these are the very attributes whose values would make the drive look extremely bad.

As you have said, the raw values for the above attributes may have multibyte components whose meanings are known only to WD. In fact here is my take on Seagate's peculiar, counterintuitive error attributes:
http://www.users.on.net/~fzabkar/HDD/Se ... R_HEC.html

My last observation is that the HDA Temperature for your good drive has current and worst values of 115 and 82. These normalised values are determined as follows:

temperature in deg C = 150 - normalised temperature

This means that your good drive appears to have experienced a temperature of 68C at some time in its life. As for your bad drive, a worst case temperature of 1 would be equivalent to 149C, which seems nonsensical.

Anyway, ISTM that retrieving MODs 01, 32, 34, and 21 from your good drive may be a prudent move, if you are willing to try. A backup would be a good idea, though. You could begin by retrieving 1 sector from MOD 01 and then determine the sizes of the required MODs.

BTW, the following information looks like it may be useful to us, although it is not directly related to ROYL drives.

Analysis of firmware components in WD Marvell drives (not ROYL):
http://nazyura.hardw.net/Part02.htm

_________________
A backup a day keeps DR away.

Correction:

The raw SMART values (for HDDs) occupy 48-bits (6 bytes). This would correspond to columns 6 - 11 in the above table for MOD 21.

_________________
A backup a day keeps DR away.

Ok, I have put my GOOD Drive through its paces, and now I have a collection of MOD files, ROMs, and Big MODs.

NOTE 1: Of course, as before, the collection of MODs has the single sector version of a big MOD, so for any of those refer to the BIG MOD collection. Example: "4.BIN is 368 KB in the GOODBIG collection, but only 512 bytes in GOODMODS.

NOTE 2: There are a few duplicate MODs and a few batch or text files. Since my bad drive was not able to retrieve MOD 32 and MOD 34, there are probably extra copies of these 2 MODs, so look out for that. 32TEST.BIN is an example.

Collection 1: ROMs.

Collection 2: MODs (some MODs are incomplete...)

Collection 3: MODs (...the full version of the Really Long MOD files)

Ok, so two questions from the original poster to all GURUs...

1. MOD 32 and MOD 34 are bad on this drive. So how do we read the MOD 32 and MOD 34 from the alternate platter (presumably head 1) to see if there is a backup?
2. Will I be able to write to the patient a correct copy of MOD 32 and 34 and then be able to recover its data?
3. Am I forced to manually do all of this with the dreaded double hot swap?!? http://www.salvationdata.com/data-recovery-examples/recover-clicking-drive01.htm and if so, how do I recreate MOD 34?!?

My assumptions are that

1. The ROM is fine. I need to verify whether the SA MODs are identical to the ROM stored on the PCB (0102, 0103, 0105, 0107 and 0109). If the two copies are different, then there is ROM corruption and it would need to be repaired ("rebuilt") if possible. This seems unlikely, as my drive is visible in BIOS and it spins up, and it seems to read *some* of the Service Area. See http://www.salvationdata.com/blog/fix-identification-problem-caused-by-corruption-of-ata-overlay-module-or-rom-content/ for why.
2. The other info from the Salvation Data page about ROYL drives is to look for ATA Overlay corruption. I noticed that the SA MOD 11 is the place where this is stored on the platters. My patient's MOD 11 is identical to the good drive's MOD 11. This drive doesn't have ATA Overlay corruption.
3. MOD 32 is the Relocated Bad Block List. My bad drive quite possibly has no relocated blocks. According to my SMART data log, there should be none. "Reallocated Sectors Count" is 0 in SMART.
4. MOD 33 is the Primary Defect List, P-List. It is apparently still fine. The P-List on the GOOD and BAD drives are very different.
5. MOD 34 is the G-list (Grown Defect List). This one seems to be generated from SMART data by Salvation Data's tool? I can't remember where I saw this, but there is a manual way to grab this data from some other MOD or from the ROM? In either case, shouldn't this be blank (and therefore identical to my good drive's) because the "Reallocated Sectors Count" is 0 in SMART?!
6. There are ECC errors, i.e. corruption in the vicinity of MOD 32 and MOD 34, but it is debatable where they can be written. If not, we may need to do t he double hot swap. If writable, the drive's LBA data will come back to like after a power cycle.