Hard drive repair (longish)

Hi there.

What does the bios report for the name of the drive on boot. The drive may have gone into "safe mode". You can check this by googling the the drive info reported by the bios. Check any articles that include the word "Ace". Apparently, only part of the data needed to access the drive information is in the firmware - the other part is on the storage platters. If there is a discrepancy, the drive kicks into safe mode and your data appears gone. The only way to recover the data is to edit and rematch the data in the two portions.

Ray

I'd like to thank everyone who made a suggestion, and give a status update on this. First of all, if you made a suggestion; thanks. For the record, setting a drive limit jumper does not help.

Through a little chicanery I obtained a second DiamondMax 10 200 Gig hard drive. Unfortunately, that also was the same firmware as the replacement. So I started to do some research.

Surprisingly, there are only 5 ICs on this drive. There is a L7250E motor / voice coil controller, which is quite well documemted, and does not have any memory. There is a 40003 IC, which I have not been able to find any solid data, but did find a siggestion that it might be a pwm encoder / decoder (possibly r/w data?). There is a K4S641632H 8 Mbyte memory chip - obviously buffer memory. There is the 25VF010 1 Mbit serial flash memory. And lastly, we have an Agere

As the next experiment, I swapped boards between the two working drives; a quick test seems to indicate there is no HDA specific information on the board.

I compared all the numbers on each IC with it's equivalent part on the other boards. In all cases, each number was either identical on all three ICs (part number, revision level, etc) or different on all three ICs (date of manufacture, lot number, etc).

The conclusion: The flash memory does NOT contain a map of bad sectors. The firmware is either in the flash menory, or in the main controller IC. For my next experiment I will try swapping this between two boards with DIFFERENT firmware.

PlainBill

This makes no sense. Flash memory is memory, and is bound to be where the map of sectors is. Because this is drive specific, it is in changeable memory. There would be no difference visually between the boards because the part numbers would not change for the differing bad sectors.

Michael

Think about it: A 200 Gig drive has 280 MILLION sectors of 512 bytes each. If only .1 % were bad, that is still 280,000 bad sectors (most drives had far more than .1% bad sectors). Please describe the algorithm that would allow placing such a map of bad sectors into a

On the other hand, 128 Kbytes of firmware would seem much more reasonable especially if the processor itself has a block of bootstrap code.

PlainBill

Hi Plain (may I call you that? :) :)

Sorry to hear you haven't quite got your pics back; glad to hear that you're still trying and learning...

Another idea to perhaps rescue your pics if I may?

If you can now easily get the drive to spin up, but bios still won't recognize it, how about opening it via api calls as a device? I think a few hex editors are capable of doing this for you, I know that WinHex will. (Use the tools, disk editor option rather than Open; then choose the phyical device rather than the logical device option [the logical device won't even appear])

At this point it should be relatively easy to search for pic headers (and footers); then simply write them to some imaginary filename on a good drive.

Course it could be a *lot* of work going through 120 gigs, but if your grand daugher and her pics are as important to you and her family as mine are to us, then....

Hope that helps, and as an aside... thank you. Kinda like taunting you about locking the barn door, but your plight has caused us to start burning and snail mailing pics on CD's between family members far more often. (my kids live in different cities) Darn, CD's are virtually free; so is postage, so well worth it for the duplicity and off-site advantages. Thanks again! Now praying for your success! :)

Take care.

Ken

Ken,

Thanks for the advice; it might yet come to that. I believe Linux might be an ideal OS for this - and give me the incentive to learn a LOT about it.

At this point I have several alternatives. I've been practicing my rework technique on a spare card, and chipquik makes removing 8 pin SMT chips a snap; once I demonstrate I can swap a pair of chips twice without damaging anything, I will be ready to do it for real.

Two other alternatives also present themselves: Several vendors claim to have the 6B200R0 drives available. Locally, several retailers carry the drive in the internal kit, I believe I've 'cracked' the labling and may be able to identify if the drive in the kit is a

PlainBill

Have you tried any of the off the shelf data recovery programs yet? There's a few of them that even let you download a somewhat functional demo to see if it sees anything off your drive.

I have done this before and it can work slowly, but well. If the drive is recognized by your BIOS, this may work. This is the same idea as using Ghost to take an image of the drive and then look at the image on another computer.

Under Linux (and most Unixes), almost all the devices in the system are represented by special files in the /dev directory. Typically, the first primary partition on your first IDE hard drive is /dev/hda1 , the second primary partition is /dev/hda2 , etc. The entire disk as a string of bytes can be accessed through /dev/hda , which works even if you don't have a partition table on it.

If the data of interest has a published file format (which is true for JPEG, TIFF, PNG, and GIF - probably the types of the pictures of interest), you can write a program to open the file that represents the whole hard drive and scan through it looking for the headers of files you are interested in. Most of these file types have headers of a defined length and either store the overall length data in the file or indicate the end of data with a unique marker, so you can also find the end of each file. You then copy each file to another drive. As Ken said, you will lose the original filename doing this, but that is easy to fix. If the pictures are straight from a digital camera in JPEG/EXIF format, and the date and time on the camera were set correctly, the date, time, and other info like flash and shutter speed are stored inside the JPEG file by the camera. Thse can be viewed with standard tools and may help you to decide when the pictures were taken, so you can decide what to rename the files to.

I would suggest Knoppix (

- Decide what PC you are going to use. Make the Knoppix CD, then boot it on this PC, making sure it works reasonably well. It deals well with most newer PCs (less than 3 or 4 years old); it might not have the right drivers for all the hardware in older PCs. If the sound card doesn't work, who cares, but if it can't see the CD or the hard disk, you might have trouble.

- Power down and attach your broken disk to this PC. Make sure the master/slave jumpers are set correctly.

- I would recommend having a place to put a copy of the broken drive. This isn't strictly necessary - you can work directly from the broken drive - but it's better to work from a copy. The obvious answer is the original hard drive for that PC, but I have had mixed luck with the support in Knoppix for writing to NTFS drives. FAT32 drives work better. If you have a working disk at least as big as your broken disk, the simplest thing is probably to format the working disk as FAT32 and attach it to the PC as well.

- Boot up Knoppix. Figure out where your hard drives are. There will probably be an icon on the desktop for your non-broken drives, but your broken drive may not show up.

- Assuming your broken drive came up as hdb, do something like this to figure out if you're going to have any luck at all:

grep 'JFIF' /dev/hdb # for regular JPEG files, or grep 'Exif' /dev/hdb # for digital-camera JPEG files, or grep 'GIF' /dev/hdb # for GIF files

It may take a little while, depending on where the first picture is on the disk. If it comes back and says 'Binary file /dev/hdb matches', then there is hope.

If you are going to make a copy of the broken drive:

- Assuming that your recovery drive came up as hdc1 , do something like this to take a complete copy of your broken drive. This is similar to what programs like Norton Ghost do. This step may take a few hours:

mount /dev/hdc1 /mnt/hdc1 # make recovery drive available to system # copy entire contents of hdb to "whole-drive.bin" in the root of hdc1, # ignoring any read errors: dd if=/dev/hdb of=/mnt/hdc1/whole-drive.bin conv=noerror

- Power down and disconnect your broken drive. You'll use the copy you made on the recovery drive from now on. Go on to the next step, writing a program.

If you are NOT going to make a copy of the broken drive:

- You need to write a program to scan through the broken drive (or the copy of it) and extract the pictures of interest. This can be in anything you know and have a compiler for; if you want to do it on the Knoppix system, I know it comes with C and Perl at least. If you have a compiler for Windows, and you made a copy of the broken drive, you can attach the recovery drive to a Windows system and recover the files there.

- When I have done this, I have it name the output files with a serial number: 00000000.jpg, 00000001.jpg, etc. These numbers will be assigned in the order that the pictures are found on the disk. You'll also need to turn on whatever support your compiler has for files bigger than 2 or 4 GB, since the copy of the broken drive will be bigger than that. The program will look something like this:

open whole-drive.bin or /dev/hdb

while not end-of-file: advance one byte found image file header? yes: read file length if it's in the header while not file length or file footer copy byte to output file advance one byte end while close output file no: proceed end while

close input file

- If you're going to recover files on the Knoppix system, you'll need a place to put the recovered files. If the recovery drive still has lots of space free (or at least as much space as you think the pictures will take), it can be a good spot. Another option would be to recover some files to the RAM disk that Knoppix sets up, then FTP them to another computer. I believe Knoppix includes CD-recording software, so you could also burn the recovered files to CD, if you have at least one CD-ROM and one CD-R drive. (The Knoppix CD has to stay in the CD drive while you're running the system.) Or, if you have a USB drive, you could recover files to that, possibly dumping them on another computer if the USB drive is small.

- Anyway, write your program, fire it up, and let it extract a few images. Look at them in an image viewer program (several to choose from on Knoppix or Windows) and debug as required. When you're happy, fire it up again and let it sit. It'll take on the order of a few hours to chug through the whole drive.

- When you're done, power down. If you recovered files to a drive, attach it to your daily driver and copy the files to its hard disk, or CD, or whatever. Use your favorite image viewer to look at the files and rename them to something sensible.

Yeah, they put plastic over the platters so your pictures and movies don't get thumb prints on them. :) All this probably means is that the on-drive buffer is bigger, so it's not a very big deal if you can't get the "correct" drive.

Matt Roberds

Well, it's time to bring this long, sad story to an end. I've given up and returned the original drive to Maxtor. For anyone who wonders, Maxtor will NOT attempt to repair a drive.

I obtained a fourth drive, with firmware identical to the original. Much to my dismay, ALL controllers reported the original hda as a 250 Gig (not 200). All working controllers reported all hdas correctly, and would read a partition table and data correctly on them.

The >Well, I really blew it this time. About a month ago I replaced my 120

Bummer. Well it's possible that the motor bearings were binding and not allowing the drive to fully spin up, might be why the original motor driver died.