Hi All; First post, gathering information on best course of action to take with this drive.

Question: Does the 7200.10 tmos use the same command set as the 7200.11?

Why do I ask? The drive in question is behaving exactly like the 7200.11 bricking fault.

Background: The drive in question belongs in a Maxtor One Touch III usb external drive. It has not had a lot of use, just general back up duty on occasion, hours wise, it's almost new. It was working fine 3 weeks ago. Last attempt win7 would not access it, reported a device fault. winXP would recognize it and load, but then reports device fault code 10. Drive was purchased a little over 5 years ago, out of warranty.
After trouble shooting and forum reading, I removed the drive from the Maxtor case, and hooked it to a win xp pc via IDE cable, 80 pin I believe. Drive spins up fine, but is not recognized by bios, so no way to get to it with any software from that point on that I am aware of. Read more forums, and it just sounds exactly like the 7200.11 issue, "drive stuck in BSY state".

Data: The information on the drive is not critical to existence. It does have a backup of my stuff from a previous life as a consultant before I got laid off. I am on a fixed income, no way do I have enough spare change to afford a professional data recovery. This is just data I would like to keep. So I'm very tempted to try the DIY unbricking technique as discussed in the 7200.11 thread. Which is why I'm asking the question, if the command set is different, then I need the correct commands. Hopefully this explains the problem, and is understandable.

cheers
cactus

This drive is completely different architecture to the 7200.11 series, and so does not suffer from the well known "busy issue" affecting that series.

The only thing I can suggest is test it with MHDD to see if is ID'd at all, then go from there. If it is not seen by MHDD then it's game over for DIY.

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

ok.......... but cannot a .10 be stuck in a bsy state? Are you saying you cannot talk to a .10 via rs232 the way you can talk to a .11? Or are you saying the command set for the .11 is totally different? So please explain the comment.

I realize the .10 does not have the firmware bug, but the thing still thinks it has a reason why it will not let bios in. I find it hard to believe that Seagate creates an entirely new command set for each and every dash version of the same drive.

As much as I love a blanket statement, I already realize it does not suffer from the bug, but it is still suffering from something. Thanks for your input.

Next,,,, I actually read the MHDD info,,,, I will download and give it a go,,,,, but in the meantime, I would still like to know if the drive can be accessed via rs232.

thanks

What was said in the first response was that the .10 architecture is completely different to the newer architecture found in the .11 series. Yes, your drive can be stuck in a BSY state, but the fix is not the same. Different problem. You cannot apply a solution for one problem as a solution to a different problem. It's like performing brain surgery for a broken leg - no going to help and will do more harm than good. The problem needs to be properly diagnosed before it can be solved.

Yes, you can talk to your 7200.10 drive via RS232.

_________________
Death is nothing, but to live defeated and inglorious is to die daily.
Data Recovery Cape Town

I have downloaded mhdd, made a boot cd, tested it on my known good hard drive a bit. Pinned up the .10 as master, swapped it with the known good drive, and powered up. mhdd finds the .10, and is currently scanning. ID and EID also provide identity info, apparently with no problems.

I'm not sure what I'm finding out, except the drive is apparently accessible, at least to mhdd, so it's not toast. I plan to let the scan complete, and take it from there.

Thanks for the prompt to try that step.

cactus

Do not let it out of sight. If it is struggling reading, meaning running into UNC and AMNF errors, stop the scan and consider sending it to a pro. If no further stress is applied on the drive, professional data recovery service will not be high. Couple of hundred dollars should do it.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

@cjack99:

That result, while good, is not expected, since all that the BIOS does to "recognise" the drive, is send exactly the same Identify Device command as MHDD does for its ID command. So it makes no sense for MHDD to work, when the BIOS didn't recognise the drive - something has changed or there is something missing from the story. Based on this result from MHDD, the BIOS should recognise it.

It's interesting that you said, before you tried MHDD, you had:


The obvious question in my mind is: Why hadn't that been done already when seeing if the drive would be recognised by your BIOS? If the drive was incorrectly jumpered, then that could explain why the BIOS didn't detect it.

FYI, I would not scan it with MHDD at this stage (I didn't see any previous poster recommend a scan in this situation), since the result doesn't help you.

(a) If the drive is fine, then scanning it is a waste of time. (b) If the drive is faulty (or has some bad blocks) then you should be spending this time (if you're accepting the risks of DIY, as you appear to be doing) cloning the drive with something appropriate which will cope with bad blocks (e.g. at least offer retry control), as the drive could become more faulty at any moment, and you may regret wasting the time on a scan by MHDD, rather than cloning what you could before things got worse. (All this is assuming you've excluded getting professional help, of course.)

Just my $0.02

why scan it....?? because I'm learning, and I wanted to know it's status, and it's more or less safe.

Results, not a single bad sector, only 112 sectors with read time over 50ms, and I got good smart read and eid / id info.

It is now having the data pulled off it with a data transfer program. Windows see's it, but really doesn't like to talk to it, so I'm working off a dos boot cd with the data transfer program on it.

Fingers crossed I'll be able to get the stuff I want most off it.

I'm guessing just working it with mhdd was enough to jog it back into life, but it is obviously not a happy camper. Right now I have about 1/2 of my data back and still going strong. After that, I dunno, maybe I'll see if I can find a pc board for it, it does not seem to have any platter or head issues, so I'm thinking the pc board has a weakness.

Thanks again for the push toward mhdd.

cheers
cactus

I politely disagree. Doing that scan, in this situation, has risks as I said before. We had someone come onto this board who spent so long scanning their (flaky) disk, that it failed completely and they couldn't then clone it! So you rolled the dice and won - this time - but I'd give the same advice to the next person, irrespective of your luck this time, because if they listened, it just might save their data...


Yes, as I said before, clone it with something suitable.


Yep, a good suggestion (as always) by pcimage [hat tip]

Edited to add: P.S. Congratulations on getting your data off the disk

Completely agree with Vulcan. Only last week I had a drive come in that the user couldn't access in Windows. Using PC3K/DE I could access the drive and managed to recover 75% of the data and then the heads went from slightly weak to dead in an instant. A headswap got back the remaining data, but the point is that running the drive during that period took it from a slightly degraded state to completely non-functional very quickly. If your drive was in that state the MHDD scanning could have killed it altogether.

You were lucky in your case and I'm happy you got your data back, but running a heavy 'test' scan on a degrading disk is not a wise move. If you were cloning then at least you were getting data off it, but scanning it was doing nothing to get your data back.

Hope this has taught you to back up! Always a good lesson learned.

_________________
Death is nothing, but to live defeated and inglorious is to die daily.
Data Recovery Cape Town

Thanks Nick

I've just realised the likely type of disk drive fault causing the different behaviour between the drive not being "seen" by the BIOS, and then being "seen" by MHDD, despite them using the same ATA command to identify the disk - but as long as the OP doesn't try to use the disk again, the actual problem is irrelevant.

Well done on getting that data recovered for your customer!