Sticktion, replcd heads, spins, heads dont move, no BIOS det

[darlingm]

Hitachi Travelstar Model IC25N030ATCS04-0, P/N 07N8326, MLC H32687

I have a Hitachi Travelstar 30GB notebook drive that had a head sticktion problem. In a HEPA 99.97% cleanroom glove box environment, I was able to rotate the spindle and get the bad head assembly onto the ramp while still spinning the spindle. (When I opened it, the heads were "parked" on the platter instead of the ramp.) I was able to remove the bad head assembly, and got the donor head assembly installed back into the ramp.

Before, the platters weren't spinning at all (the motor couldn't overcome the sticktion.) The platters are now spinning, however the heads never move at all. BIOS doesn't recognize the drive, nor did it before the head swap.

I made a post earlier about how when I took the cover off the data drive, the actuator lock fell out. When I removed the cover off the donor drive, I was able to see how the actuator lock was installed, and got the data drive's actuator lock put back properly (I believe.) I have also tried manually triggering the actuator lock. I don't think this is the problem I'm having.

I have tried the data drive's original PCB, an identical replacement PCB that I purchased stand-alone, and an identical replacement PCB that I purchased as a donor drive. I can't say the stand-alone replacement PCB works, but the donor drive worked perfectly when I tested it immediately upon receiving it. There's no NVRAM on this model hard drive.

What's the most likely issue here?


To check on my removing and installing heads on a Hitachi drive with a ramp, what's the proper procedure for removing a head assembly from a drive with a ramp in it and installing it in another? What I did on the donor drive was to unscrew the ramp, (with spacers between head arms) moved the heads closer to the platter, removed the ramp, and took the head assembly out. On the data drive, I put the head assembly in, moved the heads closer to the platter, installed the ramp, and backed the heads onto the ramp. Not sure if that was proper, but I figured that was the best way.

[drc]

One thing that can be easy to miss/overlook is that you didn't end up with multiple rubber bits in between the PCB and connection to head stack, especially since in your case it sounds like the heads aren't ever even trying to do anything.

[CK]

How close was your parts match? Was the donor an IBM or Hitachi branded version?

No NVRAM on these so PCB swap is straightforward.

I never remove the ramp. Rather, a spacer should be used to keep the heads apart.

[HDD Spaz]

what's the proper procedure for removing a head assembly from a drive with a ramp in it and installing it in another?[/b]

Not what you have done. Also.. practice practice practice. 9/10 cases of stiction, heads are good once reset. Did you you examine head after you moved them? If heads looked good, did you test the drive before removing HDA? There are so many things which you have done wrong, it's difficult to second guess what could be wrong.

How did you get access to a clean room? Is the data important on this disk or are you just practicing?

[darlingm]

Thanks for your replies. I was away for the weekend, I'll look into your suggestions today.

drccsc - Thanks, I'll check for that.

CK - The donor drive is almost an exact match. It is the same brand (Hitachi), same model (IC25N030ATCS04-0), same P/N (07N8326), same MLC (H32687), and same first two lines on the PCB (07N9085 H69067). The donor drive was unfortunately made in Feb 03 instead of May 03, and its full part number on the barcode is (07N8326H326870P32) where the data drive's barcode is (07N8326H326870P35). I haven't been able to tell what the P32/P35 refers to, but on a previous post, people said it was an identical match. (Pictures of both drives are at http://sigma.homeunix.com/hitachi).

HDD Spaz - Yes. I unfortunately noticed one of the heads was damaged when I got it back onto the ramp, so I didn't test it before removing it, fearing it would scrape the platter. Hoping there's no platter damage already, we'll see... It's not a full cleanroom, it's a fish tank with a silicon caulk'ed plexiglass lid, with rubber gloves installed through the lid to fully enclose it, with a 99.97% HEPA filter attached. I know it's not as good as a real cleanroom, but it should do for my purposes. The data is mildly important, but not very. Just a few pictures that we don't have backups of. The pictures aren't of enough value to justify the cost of sending the drive out, so if we lose them, we lose them.

CK and HDD Spaz - I'm still unsure how the heads are supposed to be removed from the ramp without removing the ramp. It didn't look to me like they could easily be backed off the ramp, since the groves at the end of the ramp away from the platters aren't in line with the groves where the heads usually are. Do you have to move the heads backward off the ramp even with this difference in grove placement? I was worried they were sensitive enough not to make it.

[CK]

They back off the ramp very easily, unless they are damaged/bent out of shape. Certainly no need to remove the ramp itself.

[darlingm]

drccsc, you were exactly right. I had two of the rubber pieces between the PCB and head stack connection.

Drive is now recognized by BIOS. When plugged in on a secondary IDE chain (by itself), booting off a different hard drive, Windows XP locks up after the splash screen. The screen goes black, and a faint clicking sound can be heard from the notebook drive if I put my ear to it. Otherwise I don't hear anything.

Thinking I had messed up on the head replacement, I moved the heads back to the donor drive. I was able to read and write data to the donor drive, proving to me that the heads were still OK.

I moved them back to the data drive, and am getting the same result when attempting to boot off a different XP drive. (I have tried a different PCB as well.) I tried using a notebook drive to USB adapter, and Windows software locks up once it tries using the drive.


I moved the drive to my Linux (CentOS) machine, and could see it just fine.

fdisk -l /dev/hda


Disk /dev/hda: 30.0 GB, 30005821440 bytes
255 heads, 63 sectors/track, 3648 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 3647 29294496 7 HPFS/NTFS

I ran ddrescue, and I think the drive is getting stuck on a spot on the platter. After 50 minutes or so, I was at this spot, and stopped operation:

ddrescue /dev/hda /dev/sde ddrescue.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued: 0 B, errsize: 0 B, errors: 0
Current status
rescued: 126992 kB, errsize: 29878 MB, current rate: 0 B/s
ipos: 27315 MB, errors: 1, average rate: 31645 B/s
opos: 27315 MB
Splitting error areas...
Interrupted by user

I can't see platter damage, and the pillow isn't silver.

fdisk -l doesn't see the drive at this point. I reboot, and it sees the drive just fine again.

I'm not sure resuming ddrescue with the logfile is best at this point. Looks like when the drive hits a spot on the platter, it freezes up and stops being recognized.

Does it sound correct, that there must be platter damage on a spot I can't see? (There's two platters so I can't check the unseen sides.) How do I proceed? ddrescue I think will automatically read in reverse if needed, but once it hits that spot on the platters, it can't see the drive without a reboot.

I wouldn't mind buying another donor drive and trying a new set of heads, but I think they're fine since when I tried them in the donor drive they worked fine.

[Zorb]

Is it ddrescue or dd_rescue? They are different. If supported, run it backward and then combine your images. Try to break up damaged areas, find where it dies running backward and go half way and start there. It will take a little work to recombine your images, but it will work. I used to use Media Tools Pro for that stuff, drive to drive with identical geometry, then image the target drive and work from that. Be sure you write zero to the target drive first.

[darlingm]

Think I got it, but am confused.

BTW, I'm using ddrescue, not dd_rescue. With a limited amount of research, ddrescue looked a bit better.

I used --input-position to skip past the hang point.

Encountered almost an error per second. Very slow, like 80KB/sec. Looking at the log, looks like it repeatedly is copying 65536 bytes (0x010000 in hex) successfully -- then failing on 1024 bytes (0x0400 in hex). Log is like:

0x5D589C200 0x00010000 +
0x5D58AC200 0x00000400 -
0x5D58AC600 0x00010000 +
0x5D58BC600 0x00000400 -
0x5D58BCA00 0x00010000 +
0x5D58CCA00 0x00000400 -

I've tried starting at the 1G position, 25G, and 29G, and it keeps running the same fail pattern.


Then, I tried using (with position 29G which failed earlier) --cluster-size=64 hardware blocks (default 128 hardware blocks) and so far it's copied 3GB without a single error. Also copying at 14MB/sec.

So, copying 128 hardware blocks at a time fails, but 64 blocks at a time works. What's that mean? Doesn't matter in the end if I get the data back, just trying to understand.

[Zorb]

Block size is many sectors it tries to read at once.

[darlingm]

Why, though, would it fail using the default cluster size, but work successfully on the same platter spots using half the cluster size?

[HDD Spaz]

You have got damage to the surface. Pro tools (or good scripting) are required to extract data or make disk image. You have done well to get this far but I am sure now you see why data recovery is so expensive.