Error Description?

[JoeNicholls]

Using PC-3000 UDMA, Drive is WD Sadle G6 family. Donor drive basically identical when comparing ROM data extracted from both donor and sick drives.

Normally drive comes up in Kernel mode, but placed into normal mode following PC-3000 instructions. Then trying to write SA tracks from donor to sick drive.

I swapped heads on a WD20EARS drive (6 head model). When I try to write SA tracks, I get the error:

Physical write error...Device Error Detected: "SERVO ERROR CODE BASE SvirActSync"

and sometimes:

Physical device error ... Device Error Detected: "SERVO ERROR CODE BASE SvirActPdFail"

Which are the same errors with the original heads when I got the drive. Do these mean the servo signals on the tracks are just screwed up, or that the donor heads are skewed to much to read the tracks at all?
The donor drive was working before I harvested the heads.

[labtech]

1) is this an experiment?

2) what were the behavior of the sick drives in failed state prior to fixing attempts?

[JoeNicholls]

1) Unfortunately, this is not an experiment.

2) The sick behavior was exactly the same. Tried heads from two different working donors, with both original PCB and Donor PCB; all with the same original symptoms.

And just incase somebody asks why don't I send it out, my answer is that I am a computer forensic examiner, working mostly on criminal cases and obviously I cannot send out disks that may contain evidence.

[labtech]

No offense, but it seems like you are not quite trained to handle the problem you are dealing with.

What has been described sounds like destroying rather than preserving evidence.

You still have not described the original behavior.

[JoeNicholls]

At the most basic level, the original behavior was that drive was not recognized. Drive would spin up and after it's attempts to initialize it would spin down. Putting it on the PC-3000 UDMA, and going into the 3K's utility it would go into kernel mode and the ERR and ABT flags would stay on. Sometimes it would go ready, but any activity involving modules (i.e. going to a platter) would go right into the ERR and ABT state with a time out "Drive Not Ready". Loading LDR from Database is successful, but nothing any further.

I have done a number of head swaps (successfully), replaced damaged firmware with PC-3000 successfully, swapped chips successfully. But I would say with this problem none of my training covered it and I have not seen it before, thus at some level your statement is correct specific to this problem.

All that aside, might you know the specifics of the error messages the PC-3000 is displaying.

[labtech]

There is no additional info with regard to the specifics of the error messages described by you as they are pretty common for Sadle G6 drives.

Since the drive was spinning down with an ABRT error, then a head(s) failure is highly likely.

These particular drives are very difficult to recover due to a variety of types of damage that prevent SA access, which is what is happening in your case. Certain critical modules are frequently getting damaged preventing normal operation and access to user data.

As I am sure other can confirm, there are few "strange" things going on with Sadle G6 and Sadle BK drives. As result, a lot of experimentation is taking in place in determining failure patterns and corresponding solutions.

I am working on two Sadle G6 cases as we speak.

I am confident to state that you will likely not get much more detailed/descriptive help pertaining to this type of drives, as there are a lot of specifics involved that can easily be omitted/misunderstood in a remote forum conversation.

I would suggest that your best chance at making significant progress in your case is contacting Ace support with a very descriptive outline of what has been attempted so far with the respective drive.

Or maybe someone else can provide more guidance...

Best wishes

[labtech]

Actually, had one more question: after putting the donor's heads back on the donors, do all the heads work as before?

[harddrivespecialist]

Before swapping heads, a lot of other tests could have been performed.

As labtech mentioned, it would be nice to know how heads perform when they are back in a donor.

[drc]

trying to write SA tracks from donor to sick drive

Aside from everything else, this is a huge red flag and should almost never even enter your mind as something to be doing.

Were you able to backup patient drive tracks first? Doesn't sound like it from your description. If writing had been successful then that would have been game over for data.

[hddguy]

If writing had been successful then that would have been game over for data.

This is what happens when you give powerful tools to inexperienced users. I also get the feeling that returning the donor heads to the donor drive wont restore the donor to an operational state which could indicate a flaw in the head change process.

The priority should be to ensure customers data remains safe during attempts to recover, if its too big for you outsource it until you can handle it in house.

[pcimage]

1) Unfortunately, this is not an experiment.

2) The sick behavior was exactly the same. Tried heads from two different working donors, with both original PCB and Donor PCB; all with the same original symptoms.

And just incase somebody asks why don't I send it out, my answer is that I am a computer forensic examiner, working mostly on criminal cases and obviously I cannot send out disks that may contain evidence.

Sending disks out for repair should be no problem, even if they do contain evidence.

We take in work from our Police force, containing evidence pertaining to very serious crimes.

Provided the correct steps are observed to preserve the chain of evidence (which we do) and the company is suitably vetted (which we are) then outsourcing is not an issue.