Bizarre WD20EARS-00MVWB0 Case

[Jared]

So I've got an odd case here.

Model: WD20EARS-00MVWB0
PCB: 2060-771698-002 Rev A

Drive was described as stopped working after moving the computer. They took it to the local computer tech, who said it wasn't spinning and referred them here. On my evaluation I find that the drive is in fact spinning.

Anyway, here's what I find. Drive ID's and shows full capacity. However, any attempt to access sectors I just get an ABR Error. All modules read and pass checksum from both heads 0 and 1. Tried replacing the PCB with same rev one, tried replacing with other similar PCB's but same result. I even tried regenerating the translator, but still it's the same. It's like nothing is wrong with the drive, but it's not working regardless.

Edit: I've also tried jump starting it from one head or the other, but on soft reset it loses readiness. Even if I just soft reset after a cold startup, it loses readiness.

Any ideas? The only thing I haven't tried yet is to use a hotstart donor. But, I'll have to track one down to try.

 

[jol]

Heads ?!

 

[Sam]

I've got a great idea in fact. Get the FW mods with a hot swap and create a Smart Donor.
My 1TB WD1001FALS no data access case (which I'm still working on by the way) is now at a point where it has very similar symptoms as this case. I was never able to get it to come ready by itself and had to do a hot swap to back up all the FW mods. Since then I've created a Smart Donor with the patient FW and ROM and been using that to start the Deepspar with. I've imaged much of the drive this way but there are hundreds of ~1000-~30000 sector sections spread evenly throughout the drive (on all heads) that I get read-timeouts on. I suspected weak heads so a couple days ago I got in some new head donors for it.
With different heads the now drive becomes ready by itself and IDs with full capacity. However, I get all ABRTs when I try to access data area. I can sporadically read and write some critical SA mods so suspect a little media damage on bottom head/platter.
With this new set of heads I am having better success with those read-timeout areas and it still loses readiness but less often than before. By now I've accepted the reality that I'm going to have to use the Smart Donor each time I start imaging this damn drive.
Good luck!

Sam

 

[Jared]

I've got a great idea in fact. Get the FW mods with a hot swap and create a Smart Donor.
My 1TB WD1001FALS no data access case (which I'm still working on by the way) is now at a point where it has very similar symptoms as this case. I was never able to get it to come ready by itself and had to do a hot swap to back up all the FW mods. Since then I've created a Smart Donor with the patient FW and ROM and been using that to start the Deepspar with. I've imaged much of the drive this way but there are hundreds of ~1000-~30000 sector sections spread evenly throughout the drive (on all heads) that I get read-timeouts on. I suspected weak heads so a couple days ago I got in some new head donors for it.
With different heads the now drive becomes ready by itself and IDs with full capacity. However, I get all ABRTs when I try to access data area. I can sporadically read and write some critical SA mods so suspect a little media damage on bottom head/platter.
With this new set of heads I am having better success with those read-timeout areas and it still loses readiness but less often than before. By now I've accepted the reality that I'm going to have to use the Smart Donor each time I start imaging this darn drive.
Good luck!

Sam

This one doesn't act like bad or weak heads at all. It reads and writes modules at full speed, comes ready very quickly, etc. It really seems like nothing is wrong until you try to read a sector. It's almost like it's a bad translator module, but everything seems to check out. I'll be trying a few more things this afternoon so hopefully can crack this one.

 

[Jared]

OK, after some more investigation seems that the problem is with Head 5. This drive is just too stupid to actually disable heads when you disable them in RAM and they keep getting re-enabled. Didn't find the issue until I did some more extensive read/write testing in an unused part of the SA.

 

[Amarbir[CDR-Labs]]

OK, after some more investigation seems that the problem is with Head 5. This drive is just too stupid to actually disable heads when you disable them in RAM and they keep getting re-enabled. Didn't find the issue until I did some more extensive read/write testing in an unused part of the SA.

Jared ,
Change the HSA and See again .BTW sometimes we have morons playing with P list and Glist .Another great way is to backup G And P List create the same then regenerate translator and see is the situation will improve.Of course this is Not a Data Recovery Solution But You do Have Backup

 

[Jared]

No, it's definitely a problem with head 5. Trying to find a donor now to get a complete quote, but I don't think the customer is going to approve this anyway.