Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

ST2000DL003 (Seagate Barracuda LP Green 2000GB) suddenly ceases

- - - - -

  • Please log in to reply
40 replies to this topic

#26
Kelsenellenelvian

Kelsenellenelvian

    WPI Guru

  • Developer
  • 8,760 posts
  • Joined 18-September 03
  • OS:Windows 7 x64
  • Country: Country Flag
That's right I read it wrong


How to remove advertisement from MSFN

#27
danielholm

danielholm
  • Member
  • 4 posts
  • Joined 12-March 15
  • OS:95
  • Country: Country Flag
I just got this issue after doing a factory reset of my NAS. Been having a discussion with the tech support at Seagate, which sucked, then finding this lovely thread. A serial cable has been ordered.

But:

This method seems to be very promising. I have one of these drives and I tried shorting it at the points shown above and then tried connecting it as an external hard drive. My computer can now see the drive and it's contents but the access is extremely slow. I did not do the terminal commands yet as I had to order the hardware to do so and haven't received it yet. I'm assuming that after I do the terminal commands it should fix the slow access issue. I'll report back once I receive the hardware and attempt the terminal commands, but I'm pretty confident it will work.


Are you saying you did the shorting of the read points without the use of a serial cable and terminal? I might want to try that as well, but I don't know when to start shortening it?

#28
danielholm

danielholm
  • Member
  • 4 posts
  • Joined 12-March 15
  • OS:95
  • Country: Country Flag

Ok, so I got two drives of this model (ST2000DL003-9VT166) that both died at the same time after a power shortage of ReadyNAS 1100 I got. Neither of them was found in a regular computers BIOS, but they where identified by the NAS unit, altough they failed to initialize - Error messages said that the drives were BUSY.

 

After some paniciing and fury I found this thread, ordered a CA-42 (copy) cable. Got it the other day, took it apart and today I finally got acces using serial connection.

 

Drive 1: Success.

Before I got the cable I shortned the two pins (found in image in post #9), hoping that would work solely - it did not. So when I go the cable I connected it and finally got some output from the boot process:

Rst 0x40M
 MC Internal LPC Process
(P) SATA Reset

 User Data Base  00991680

 MCMainPOR: Start: 
 Check MCMT Version: Current
 MCMainPOR: Non-Init Case
 MC Seg Disc and Cache Nodes:  4011A624  40118734
 Seg Write Preamble VBM start: 000010A7 end: 000010CE
  Footer - start: 000010D0 end: 000010F7
 Seg Read Preamble VBM - start: 000010F9 end: 00001120
  Footer - start: 00001122 end: 00001149
Reconstruction: MCMT Reconstruction Start 
  Max number of MC segments 22E0
 Nonvolatile MCMT sequence number 00000002
 [RSRS] 0000
Reconstruction: Completed 0: HeadPtr was unwritten 
[MCMTWS]
 MCMainPOR: MCTBufferPtr->Header.MCStateFlagsDisc = 00000001
 MCMainPOR: MCTBufferPtr->Header.MCTStateFlags = 0000002A
 MCMainPOR: MCStateFlags = 00000001

 MCMainPOR: Feature Enabled...

There the output ended. Pressing Ctrl+Z did not do anything. So I started to short the pins, and I got:

InitiateMarkPendingReallocateRequest for disc_lba: 08EFAE2A

After that the drive sounded a bit more than usual and after each periodic sound it added a "!" at the end of "08EFAE2A".

I tried Ctrl+Z again and finally got access! So I ran the commands:

F3 2>Z
(took around 14 secs to spin down)

F3 2>U

Ctrl+Z

F3T>i4,1,22

F3 2>/1

F3 1>N1

Then powered down.

Connected the drive to a computer and it was found in BIOS. Booted Ubuntu, formated it, ran some SMART tests. It's now connected to my NAS again and is initializing.

 

Disk 2: Bad..

 

Booting:


(P) SATA Reset

User Data Base 00991CC0

MCMainPOR: Start:
Check MCMT Version: Current
MCMainPOR: Non-Init Case
MC Seg Disc and Cache Nodes: 4011A624 40118734
Seg Write Preamble VBM start: 000010A7 end: 000010CE
Footer - start: 000010D0 end: 000010F7
Seg Read Preamble VBM - start: 000010F9 end: 00001120
Footer - start: 00001122 end: 00001149
Reconstruction: MCMT Reconstruction Start
Max number of MC segments 22E0
Nonvolatile MCMT sequence number 000000A6
[RSRS] 0061
Reconstruction: Completed 0: HeadPtr was unwritten
[MCMTWS]
MCMainPOR: MCTBufferPtr->Header.MCStateFlagsDisc = 00000041
MCMainPOR: MCTBufferPtr->Header.MCTStateFlags = 00000022
MCMainPOR: MCStateFlags = 00000041

MCMainPOR: Feature Enabled...

Rst 0x40M
MC Internal LPC Process
LED:000000BD FAddr:000058E4

Ctrl+Z not working. Power down, power up, shortned the pins the whole time. The drive gave a loud beep. Nothing else changed.

 

After a few retries I got access to the terminal by using the window (of a few seconds) between "Feature enabled..." and "LED:000000BD FAddr:000058E"

 

Ran the same commands as for disk 1. Powered down, connected it to a PC - No change: it still was not found my BIOS.

 

Plugging it back into serial connection, running the commands a few more times, restarting the drive and found that the "LED:000000BD FAddr:000058E" issue persisted.

 

Trying the "paper over header, under PCB". Gave nothing. At all. So I thought (I know....) "The hell with it!" (I know... I know.." and then I ran:

>m0,2,2,,,,,22
User Partition Format Successful - Elapsed Time 0 mins 00 secs        
Zone re-format was skipped.

No change when power cycling. Ran the first commands that worked for the dirst disk anothe time, no change, so I started to shortned the pins even longer after restart of the drive. No I started to get these new messages:

FAIL Op=0900 Resp=0005
FAIL Op=0600 Resp=0005
No HOST FIS-ReadyStatusFlags 0002A1A4

huh? Pressing Ctrl+Z again - still got terminal access. But now when I ran the previous commands, including m0(...) and so on, I started to get:

Init SMART Fail

Then I get kicked out of the terminal and the error message is followed by the old:

Rst 0x40M
 MC Internal LPC Process
LED:000000BD FAddr:000058E4

Using the window to get into terminal again I can still spin up and down, but N1 or m0 gives me "Init SMART fail" and I get kicked out.

 

And that's where I am at right now.


Edited by danielholm, 25 March 2015 - 09:34 AM.


#29
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,768 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Well, with all due respect :) your reports are either "vague" :w00t: or meaningless :ph34r: (or BOTH).

 

The only (BTW completely unreferenced/untested/unconfirmed) related post says to NOT run "all commands" (WHICH ones?), so I wonder what you did/have been following. :unsure:

 

 

It seems to me clear that:

a. your drives EITHER did not suffer from the same illness OR you cured them somehow differently

b. you completely fail to DETAIL which cure(s) you applied to which drive EXACTLY

 

Don't take it as an offence :), but if you posted the above in order to hopefully help  someone with a disk suffering from the same issue, your post is not useful as it misses a lot of information on WHAT EXACTLY you did successfully on the first disk drive, on the other hand, if it is to look for help, it is as well not clear WHAT EXACTLY you did unsuccessfully on the second disk drive.

 

It would be nice if you could (no matter what is the reason of your post) report in more detail what happened and the symptoms they have (I presume that they are/were "BSY") and as well EXACTLY what you did on the one (and on the other).

 

jaclaz


Edited by jaclaz, 25 March 2015 - 09:02 AM.


#30
danielholm

danielholm
  • Member
  • 4 posts
  • Joined 12-March 15
  • OS:95
  • Country: Country Flag

Well, with all due respect :) your reports are either "vague" :w00t: or meaningless :ph34r: (or BOTH).

 

The only (BTW completely unreferenced/untested/unconfirmed) related post says to NOT run "all commands" (WHICH ones?), so I wonder what you did/have been following. :unsure:

 

 

It seems to me clear that:

a. your drives EITHER did not suffer from the same illness OR you cured them somehow differently

b. you completely fail to DETAIL which cure(s) you applied to which drive EXACTLY

 

Don't take it as an offence :), but if you posted the above in order to hopefully help  someone with a disk suffering from the same issue, your post is not useful as it misses a lot of information on WHAT EXACTLY you did successfully on the first disk drive, on the other hand, if it is to look for help, it is as well not clear WHAT EXACTLY you did unsuccessfully on the second disk drive.

 

It would be nice if you could (no matter what is the reason of your post) report in more detail what happened and the symptoms they have (I presume that they are/were "BSY") and as well EXACTLY what you did on the one (and on the other).

 

jaclaz

 

No offence taken; you are of course perfectly right.

 

I have updated the previous post.


Edited by danielholm, 25 March 2015 - 06:25 PM.


#31
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,768 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

 

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/...eases/?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...hp?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...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



#32
danielholm

danielholm
  • Member
  • 4 posts
  • Joined 12-March 15
  • OS:95
  • Country: Country Flag

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,,,,,22
Max Wr Retries = 00, Max Rd Retries = 00,  Max Iterations = 01, Max Certify Rewrite Retries = 001B

Init SMART Fail
Rst 0x40M
 MC Internal LPC Process
LED:000000BD FAddr:00004C51
F3 1>N1,,22
Init SMART Fail
Rst 0x40M
 MC Internal LPC Process
F3 T>F,,22
(D) SATA Reset

 SIM Error 1009 LBA 00000000000643FB FD FCFFF3FF
 RW Error 00000080
F3 T>V40
DiagError 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>V80
DiagError 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>X

Head 00 Resistance 00EB
Head 01 Resistance 00B7
Head 02 Resistance 00E0
Head 03 Resistance 00D3
Head 04 Resistance 00E7
Head 05 Resistance 012B
F3 T>V8
 Servo Flaws List
  log log   phy
 head cyl   cyl  wedge  status
Log head 0: entries        0
Log head 1: entries        0
Log head 2: entries        0
Log head 3: entries        0
Log head 4: entries        0
Log 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            0

Head 0: entries      1        slips        0
Head 1: entries      0        slips        0
Head 2: entries      0        slips        0
Head 3: entries      0        slips        0
Head 4: entries      0        slips        0
Head 5: entries      0        slips        0
  Total Entries      1  Total Slips        0


#33
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,768 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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



#34
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,370 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

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). :(



#35
baws

baws
  • Member
  • 3 posts
  • Joined 16-July 15
  • OS:Vista Home Premium x86
  • Country: Country Flag

I saw this video regarding the 7200.12 : https://www.youtube....h?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.



#36
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,768 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

I saw this video regarding the 7200.12 : https://www.youtube....h?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/...1-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, 17 July 2015 - 03:57 AM.


#37
baws

baws
  • Member
  • 3 posts
  • Joined 16-July 15
  • OS:Vista Home Premium x86
  • Country: Country Flag

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, 17 July 2015 - 08:15 AM.


#38
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,768 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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/...eases/?p=990707

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

http://www.msfn.org/...ases/?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/...-bios-suddenly/

 

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

 

jaclaz



#39
baws

baws
  • Member
  • 3 posts
  • Joined 16-July 15
  • OS:Vista Home Premium x86
  • Country: Country Flag

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/...eases/?p=990707

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

http://www.msfn.org/...ases/?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/...-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!



#40
Kelsenellenelvian

Kelsenellenelvian

    WPI Guru

  • Developer
  • 8,760 posts
  • Joined 18-September 03
  • OS:Windows 7 x64
  • Country: Country Flag

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)



#41
jaclaz

jaclaz

    The Finder

  • Developer
  • 15,768 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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/...ubles/?p=897151

 

jaclaz






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users