viinikala

ST2000DL003 (Seagate Barracuda LP Green 2000GB) suddenly ceases

45 posts in this topic

 

I have updated the previous post.

 

Good, thanks. :)

The issue here (BTW it is perfectly normal as the related info is scarce and very often "vague", incorrect or unverified/not repeatable), is  that the only *somehow* related post/info we have:

http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=990707

explictly says to NOT run the "m0,2,2,,,,,22" (or similar) commands, on these drives, exactly because the result will be an "unrecoverable" (at least for the scarce knowledge we have on these specific drives' firmware) "No HOST FIS-ReadyStatusFlags  " Status.

So, I understand the "The hell with it!"" part, but in the end you entered yourself voluntarily in the No Way Out alley explicitly marked with a "No Way Out" sign. ;)

 

Somehow (by recklessly ;) doing what you were suggested NOT to do) you made the disk enter a new (and uncommon since seemingly it enters that state only as a result of issuing the command you should have NOT issued) disk state.

 

Now you have nothing (really nothing) to loose, as likely (according to these info here):

http://forum.hddguru.com/viewtopic.php?f=13&t=27731

(provided that - as I suspect - applies to the "green" drives as they are more similar to the 7200.12 than to the 7200.11) even if somehow you can regain use of the drive, very likely you will have a reduced area usage, you can try any of the "diagnostics" command like the V1, V2, V3, V4, V40, etc. that you can find googling for "Seagate Init Smart Fail", but I don't think that without special hardware you will ever get the drive back :(.

It seems like the "right" command (for the 7200.12 and cannot say if it applies to a LP Green :unsure:) to regenerate the translator when a "NRG-LIST sector" (whatever it is) exists:

http://forum.hddguru.com/viewtopic.php?f=1&t=29885

is:

m0,6,3,,,,,22

but probably/possibly it is too late since you already ran the "m0,2,2,,,,,22" one.

jaclaz

0

Share this post


Link to post
Share on other sites

I know it was stupid. But I was ready to give it a go anyway. Nothing to loose but a drive I couldn't get to work anyway, I thought. And getting 1/2 drives to work is pretty good anyways, haha  :thumbup 

 

This is a part of my backup backup (backup), so I'm not worried about any data loss. I just wanted to use the drives I bought.

 

I've run a LOT of commands now and I'll post the outputs if wanted. But maybe I should start another thread for that(?)

 

It does not look good for this one. SMART is constantly failing :whistle:

 

What was it that I actually did by that command? I've read some about that I might have screwed up the drive so that some of the heads wont be used, but I dont care, really. If I could just get out a few hundred gigs from it, I'd be happy, (or happier, haha)

 

Posting the shortes outputs and the longer in a thread, if needed:

F3 T>m0,6,2,,,,,22Max Wr Retries = 00, Max Rd Retries = 00,  Max Iterations = 01, Max Certify Rewrite Retries = 001BInit SMART FailRst 0x40M MC Internal LPC ProcessLED:000000BD FAddr:00004C51
F3 1>N1,,22Init SMART FailRst 0x40M MC Internal LPC Process
F3 T>F,,22(D) SATA Reset SIM Error 1009 LBA 00000000000643FB FD FCFFF3FF RW Error 00000080
F3 T>V40DiagError 00000007 Invalid Diag Cmd Parameter
F3 T>F0A2,01,22(D) SATA Reset SIM Error 1009 LBA 00000000000643FB FD FCFFF3FF RW Error 00000080Byte:00A2:       RWRecoveryFlags = 01
F3 T>V80DiagError 00000007
F3 2>.Current R/W User LBA 000000000000 LLL CHS 000000.0.0000 PLP CHS 000000.0.0000 R/W Status 1 R/W Error 00000080 Ready
F3 7>XHead 00 Resistance 00EBHead 01 Resistance 00B7Head 02 Resistance 00E0Head 03 Resistance 00D3Head 04 Resistance 00E7Head 05 Resistance 012B
F3 T>V8 Servo Flaws List  log log   phy head cyl   cyl  wedge  statusLog head 0: entries        0Log head 1: entries        0Log head 2: entries        0Log head 3: entries        0Log head 4: entries        0Log head 5: entries        0      Total Entries        0
F3 T>V1 User Slip Defect List                            log log   log     phys   phys        LBA    span   cumm   cyl  hd  sctr zn   cyl   sctr     SFI      PBA           0      0      0     0  0     0   0      0     0        9            0Head 0: entries      1        slips        0Head 1: entries      0        slips        0Head 2: entries      0        slips        0Head 3: entries      0        slips        0Head 4: entries      0        slips        0Head 5: entries      0        slips        0  Total Entries      1  Total Slips        0
0

Share this post


Link to post
Share on other sites

Yep :), it's refreshing to see someone seeing the glass as half full for a change :thumbup .

 

From the little I seem to understand reading (mainly between the lines) the scarcely information available (which I have to repeat is related to 7200.12 and not necessarily applies to LP green drives) it seems like a "list or database of something" (please not the intentionally vague description) has been moved from a location on the PCB (a chip) to a location on the actual disk platter and that the the m0, etc. command *somehow* clears an address or reference to this area (or resets i to the "old" location on chip) and then the firmware attempts to find the SMART data where it is not and fails, and same applies to the reported reduced LBA access, which is most probably connected to a pointer that is miscalculated or looked for where it is not.

 

You can try to see if any of the good guys at http://malthus.mooo.com/have any idea or more (or better information).

 

This thread is perfect to report the output of the various commands you try :), though I don't think that it is in any way probable that by pure chance you will find a "miracle command" :(, the output of the commands on your disk drive may hopefully have some use, at least as a reference.

 

jaclaz

0

Share this post


Link to post
Share on other sites

Apparently the guys at Seagate, after having bought out Maxtor a while ago, decided to use the old technique that has failed certain Maxtor series long time ago, most notably the N40P: part of the firmware in the chip and part on the platter(s). Incidentally I had a failure with a N40P recently and turned to the HDDGuru guys for help, which I obviously never got.

For ATA drives there were a few tools (I used HDD Repair 2.0) but I know of none that can work with SATA/II/III.

 

Anyway, what I wanted to say is that - as noticed by some users already - replacing the PCB would be useless since the firmware's modules on the platter(s) would not match those on the PCB. Unfortunately I don't have the knowledge to help in this case, as I couldn't even fix my N40P (which belongs to a friend, actually). :(

0

Share this post


Link to post
Share on other sites

I saw this video regarding the 7200.12 : https://www.youtube.com/watch?v=oI3hDgfssu0

 

where he doesnt mention a shorting,

 

 

And I read here that this command should be used:

 

m0,6,3,,,,,22

 

instead of:

 

m0,2,2,,,,,22

 

 

Im a bit confused here.

0

Share this post


Link to post
Share on other sites

I saw this video regarding the 7200.12 : https://www.youtube.com/watch?v=oI3hDgfssu0

 

where he doesnt mention a shorting,

Then trust the video and don't do the shorting.

If you are NOT locked out with a LED:00000xxx FAddr:0000yyyy error, you are fine :), otherwise you might need to find way to exit that loop :whistle:.

The 7200.12 is NOT a "LP green" model like we are talking about in this thread, however, see:

http://www.msfn.org/board/topic/157329-barracuda-lp-no-not-a-720011-nor-a-720012/

 

And I read here that this command should be used:

No, you don't.

You read here that a user who used blindly the commands suggested as a remedy for a given illness on a completely different issue/problem had a 50% rate of success (one disk out of two) and since there was nothing to lose on the disk that he failed to revive, was suggested to try some other commands, in the remote hypothesis that they could work.

DO NOT EVEN THINK of running any command unless you are pretty sure of the exact drive model involved, and the exact nature of the issue.

 

DO NOT ASSUME that the procedure for another disk model can apply to your disk, a video may be a good visual reference for the generic process of accessing the disk, but nothing more.

 

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Thanks!

 

Im pretty new at this. Would rather give it to one of you guys  and give you some money, but You don't live near me :)

 

 

The Drive I have is this:

 

Barracuda LP 2000GB

Serial: 5YD1873L

ST2000DL03

P/N: 9VT166-301

F/W :CC32

 

b156750.jpg

PCB here : PCB

Edited by baws
0

Share this post


Link to post
Share on other sites

Yep :), but the real problem (besides geographical distance) is that we know very little about a single (actually two) very specific issues originating from a same very specific firmware implementation on a different (though similar) drive, the 7200.11, and we know even less :w00t::ph34r: on these "LP Green" things, specifically we have a single "vague" report of success coming from a post on the Seagate board, quoted here:

http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=990707

and (maybe) a single "even more vague" confirmation:

http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=1091946

 

Please do note how the ONLY (as said "vague" and not properly confirmed) source runs only a "i" command that clears (possibly without any real need :unsure:) the g-list and then runs just a "N" command (clearing the S.M.A.R.T.) and EXPLICITLY tells you to NOT run any "m" commands:

 

DONT GIVE m0,2,2,,,,,22 m,6,2,,,,,22 OR ANY SAME
ALL THE TERMINAL LOG AS YOU CAN SEE REGARDING "No HOST FIS-ReadyStatusFlags 0002A1E1" THIS IN THIS POST ARE VICTIM OF THIS M-FORMAT COMMAND AS PER MY KNOWLEDGE EVEN I HAVE MADE SAME MISTAKE.

 

 

and we have at least a confirmation that running the  "m0,2,2,,,,,22":

http://www.msfn.org/board/topic/161029-seagate-barracuda-lp-green-is-not-recognized-in-bios-suddenly/

 

actually further "bricks" the device into a "No HOST FIS-ReadyStatusFlags 0002A1E1" :(.

 

jaclaz

0

Share this post


Link to post
Share on other sites

Yep :), but the real problem (besides geographical distance) is that we know very little about a single (actually two) very specific issues originating from a same very specific firmware implementation on a different (though similar) drive, the 7200.11, and we know even less :w00t::ph34r: on these "LP Green" things, specifically we have a single "vague" report of success coming from a post on the Seagate board, quoted here:

http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=990707

and (maybe) a single "even more vague" confirmation:

http://www.msfn.org/board/topic/150475-st2000dl003-seagate-barracuda-lp-green-2000gb-suddenly-ceases/?p=1091946

 

Please do note how the ONLY (as said "vague" and not properly confirmed) source runs only a "i" command that clears (possibly without any real need :unsure:) the g-list and then runs just a "N" command (clearing the S.M.A.R.T.) and EXPLICITLY tells you to NOT run any "m" commands:

 

DONT GIVE m0,2,2,,,,,22 m,6,2,,,,,22 OR ANY SAME

ALL THE TERMINAL LOG AS YOU CAN SEE REGARDING "No HOST FIS-ReadyStatusFlags 0002A1E1" THIS IN THIS POST ARE VICTIM OF THIS M-FORMAT COMMAND AS PER MY KNOWLEDGE EVEN I HAVE MADE SAME MISTAKE.

 

 

and we have at least a confirmation that running the  "m0,2,2,,,,,22":

http://www.msfn.org/board/topic/161029-seagate-barracuda-lp-green-is-not-recognized-in-bios-suddenly/

 

actually further "bricks" the device into a "No HOST FIS-ReadyStatusFlags 0002A1E1" :(.

 

jaclaz

 

Ohh man.

 

Not good at all, why can´t the technicians at seagate give an answer on this?

Damnit!

0

Share this post


Link to post
Share on other sites

The technicians at seagate still BARELY admit this issue actually exists and that there is a actual fix for it. They've tried to bury it since it started. Honestly they should send out communication kits and instructions on how to fix it. (Free of charge of course they have destroyed easily millions of dollars in valuable properties with these drives)

0

Share this post


Link to post
Share on other sites

The technicians at seagate still BARELY admit this issue actually exists and that there is a actual fix for it. They've tried to bury it since it started. Honestly they should send out communication kits and instructions on how to fix it. (Free of charge of course they have destroyed easily millions of dollars in valuable properties with these drives)

Well, it's not the fault of the technicians, as always the issue is the marketing and management that are too short sighted to understand how they could easily have turned this issue into a brand consolidation at nearly no cost, by following the advise of a stranger on the internet (from time to time they do have good ideas ;)):

http://www.msfn.org/board/topic/128092-seagate-barracuda-720011-troubles/?p=897151

 

jaclaz

0

Share this post


Link to post
Share on other sites

What about buying an exact same hard drive and switch the pcb?

0

Share this post


Link to post
Share on other sites

Won't work, but may clobber both for good.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.