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

# Seagate Barracuda 7200.11 Troubles

1247 replies to this topic

### #1051 Gradius2 Posted 28 January 2009 - 10:10 AM

IT Consultant

• Member
• 240 posts
• Joined 16-January 09
• OS:Windows 7 x64
• Country:
Very nice arguments, this recalls my old days on CBBS/BBS age back in 1985.

Seagate boot-of-death analysis - nothing but overhyped FUD

Of course that statement above is a BIG bad joke from Seagate or whatever the source is.

To put the things simple to everyone the best proof is looking how many viewers we got on topics here related to Seagate's problems (aka 7200.11 syndrome).

Now lets just do a simple google search, by entering:

"Seagate 7200.11 failing": I got 72,100 links

The bad thing is I don't know how many those links might be related to the same site, so I'll take everything divided by 4:

If we take at least four drives are necessary for someone to write about this issue on the web (hence divided by 4), and at least 10 people will read that (because they have the same issue), and they all will have an average of 2 drives with problems, then we would have: 72,100/4*10*2 = 360,500 defective drives, until 371,000/4*10*2 = 1,855,000 drives (in rough math).

Now, lets looks to those who knows the issues those drives are reporting:

16,080 links, unfortunately we cannot apply the same "math" as above, since this is a bit different, few people would know relatively well the problem, and will try to fix the thing themselfs, I would estimate as low as 1% of them. So in best case scenario (for Seagate) they're just by x10 factor, and worst, by x100 factor. So 16,080 * 10 = 160,800 until 16,080 * 100 = 1,608,000.

In both cases, it ultrapasses 1 million mark, coincidence?

overhyped FUD they said? LAUGH!

Edited by Gradius2, 28 January 2009 - 10:13 AM.

"Two things are infinite: The Universe and Human stupidity; and I'm not sure about the Universe." Albert Einstein

### #1052 SpXuxu Posted 28 January 2009 - 12:20 PM

SpXuxu
• Member
• 7 posts
• Joined 19-January 09

overhyped FUD they said? LAUGH!

I think i can understand what Seabreak (or Seabrick) means with that

FUD = FU...keD

(fill in the blanks)

Edited by SpXuxu, 01 February 2009 - 06:28 PM.

### #1053 jaclaz Posted 28 January 2009 - 12:34 PM

jaclaz

The Finder

• Developer
• 16,627 posts
• Joined 23-July 04
• OS:none specified
• Country:

Now lets just do a simple google search, by entering:

"Seagate 7200.11 failing": I got 72,100 links

Sorry to say so , but that's not really a "valid" argument, as I (and some other people) see it :
http://homepages.tes...ess-metric.html

jaclaz

### #1054 mikesw Posted 28 January 2009 - 12:39 PM

mikesw

• Member
• 365 posts
• Joined 05-October 05
The victory tool v3.4 from hddguru seems to be MSDOS based and require a floppy disk.

Is there a version that runs on windows?

Edited by mikesw, 28 January 2009 - 12:39 PM.

### #1055 jaclaz Posted 28 January 2009 - 12:42 PM

jaclaz

The Finder

• Developer
• 16,627 posts
• Joined 23-July 04
• OS:none specified
• Country:

The victory tool v3.4 from hddguru seems to be MSDOS based and require a floppy disk.

Is there a version that runs on windows?

Victoria

Looky here:
http://www.benchmark...ml?/be_hdd.html

jaclaz

### #1056 Gibby Posted 28 January 2009 - 01:34 PM

Gibby
• Member
• 8 posts
• Joined 28-January 09

Yep , and we don't even have a clear idea on WHICH events are logged and HOW MANY such events take place in an "average powered on hour".

True, but we don't have to know. The probability of a drive failing is the same as long as at least one event is logged per power cycle.

If, as it has been hinted/reported somewhere on the threads, a S.M.A.R.T. query raises an event that is actually logged, we will soon fall in the paradox that the more you check your hardware status the more prone it is to fail.....

No, the chance of a drive failing due to this condition is zero unless it is powered off.

All that matters is that the event counter changes at all from power-on to power-off. It does not matter whether it increases by 1, or by 50 or by any other value as long as such values are equally probable.

But the events are hardly equally probable. It's much more likely that you're going to get a very small number each power cycle. The chances of dozens or hundreds of entries each power cycle are almost non-existant unless your drive is hosed to begin with.

And consider this: if the log incremented by EXACTLY one each power cycle (I don't know if that's even possible), what's the probability an (affected) drive will fail? It's 100%. It will fail with certainty because it WILL occur on the 320th power cycle. It will take just under a year or so for this to happen for a lot of home users assuming a power cycle per day. Just an example of course. We have to consider that a lot of drives from the list can be seen failing after around 60 - 100 days. Would this be something roughly like 60 - 100 power cycles for those drives? So maybe for the first 'batch' of bad drives, you're seeing something like a 3 - 5 log entries on average per power cycle.

My point is that the probability of an affected drive failing may be as high as something like 3, 4 or 5:1. We have probably not seen the bulk of failures yet - it's too early! And the lower the average number of log entries per power cycle, the higher the probability eventually becomes for the initial 320th entry and each 256th circulation after that. It will take longer, i.e., more power cycles, but there's a better chance of hitting the bad entry each complete cycle. Even if the average number of entries is very low, like .5 per power cycle, there is an extremely high chance of the drive failing - eventually. It's just going to take around 640 power cycles, but you are unlikely to skip ending exactly on entry 320 (or x*254 thereafter).

Figuring out the probability of failure on any single power cycle isn't really useful. The question most 7200.11 owners have is: What are the chances my drive will fail AT ALL in the next year or two?

Edited by Gibby, 28 January 2009 - 01:51 PM.

### #1057 pichi Posted 28 January 2009 - 03:25 PM

pichi

Member

• Member
• 166 posts
• Joined 03-January 09
Seagate modify commands in the new firmware:

SD15:
Level T 'i': Rev 0001.0000, Overlay, InitDefectList, i[DefectListSelect],[SaveListOpt],[ValidKey]
Level T 'm': Rev 0001.0000, Flash, FormatPartition,
m[Partition],[FormatOpts],[DefectListOpts],[MaxWrRetryCnt],[MaxRdRetryCnt],[MaxEccTLevel],[MaxCertif
yTrkRewrites],[ValidKey]

SD1A:
Level T 'i': Rev 0011.0000, Overlay, InitDefectList, i[DefectListSelect],[SaveListOpt],[ValidKey]
Level T 'm': Rev 0012.0000, Flash, FormatPartition, m[Partition],[FormatOpts],[DefectListOpts],[MaxWrRetryCnt],[MaxRdRetryCnt],[MaxEccTLevel],[MaxCertif
yTrkRewrites],[ValidKey],[DataPattern]

Questions:
¿What is [DataPattern] in Level T 'm'?
Can be SD1A bricks repaired with the new commands table?

Edited by pichi, 28 January 2009 - 03:27 PM.

### #1058 sieve-x Posted 28 January 2009 - 06:51 PM

sieve-x

Newbie

• Member
• 12 posts
• Joined 19-January 09

Questions:
¿What is [DataPattern] in Level T 'm'?
Can be SD1A bricks repaired with the new commands table?

They should work as long you are were dealing with the same issue but SD1A
fixes that and then 'bricking' cause/solution would be something different. About
[DataPattern] I would guess the name says what it does (create/fill data pattern).

Updated my previous post #1045 to shed some light around root cause and S.M.A.R.T.

Edited by sieve-x, 29 January 2009 - 01:12 AM.

### #1059 pichi Posted 29 January 2009 - 04:24 AM

pichi

Member

• Member
• 166 posts
• Joined 03-January 09
I have developed programs to automatize the repairing process, to do it more easy.
Some people have probed these programs and them works.
I am colaborating with Fatlip to give a worldwide low cost solution (adapter and torx), there is people that cannot find adapters.
Soldering station aren't neccesary, electronic knowledge neither.
The work is behind and thanks to a lithuanian webpage we have the solution:
http://yura.projekta...720011_ES2.html
Due to some people that only know copy and paste, and later request donations ... I am thinking if I will give the programs or not.

### #1060 jaclaz Posted 29 January 2009 - 04:45 AM

jaclaz

The Finder

• Developer
• 16,627 posts
• Joined 23-July 04
• OS:none specified
• Country:

I have developed programs to automatize the repairing process, to do it more easy.

That would be a great thing.

I have a few PM's by people who don't know English very well, so I'm trying to find the time to translate existing guide (into Italian), but I am a bit reluctant as this "kind" of people tends to be also not particularly "tech savvy" and the procedure is fairly complex for the newbie, and the risk of somehow "frying" the drive by mistake is great.

Having something along the lines of what I hinted here:
http://www.msfn.org/...o...28807&st=48

tested and working, could make the difference.

About the other point, of course you are free to choose your way, but:

We make a living by what we get, but we make a life by what we give.

jaclaz

### #1061 Oliver.HH Posted 29 January 2009 - 08:12 AM

Oliver.HH
• Member
• 7 posts
• Joined 28-January 09

All that matters is that the event counter changes at all from power-on to power-off. It does not matter whether it increases by 1, or by 50 or by any other value as long as such values are equally probable.

But the events are hardly equally probable. It's much more likely that you're going to get a very small number each power cycle. The chances of dozens or hundreds of entries each power cycle are almost non-existant unless your drive is hosed to begin with.

You are right. My statement was an oversimplification.

And consider this: if the log incremented by EXACTLY one each power cycle (I don't know if that's even possible), what's the probability an (affected) drive will fail? It's 100%. It will fail with certainty because it WILL occur on the 320th power cycle.

If you assume that the log is initially empty (event counter at 0), that's certainly true. To be more precise, the probability of the drive failing would be 0% on the first 319 days, jumping to 100% on day 320.

Figuring out the probability of failure on any single power cycle isn't really useful. The question most 7200.11 owners have is: What are the chances my drive will fail AT ALL in the next year or two?

Absolutely. That's in line with what I intended to point out. While the probability of anything failing is 100% in an infinite number of years, these drives are very likely to fail in their first year of service. My calculation estimates a 76% chance of failure within a year. Real numbers might be even worse.

I'v quickly calculated the chances of drive failure given a certain average number of log entries per power cycle. Again I've ignored the initial 320 boundary, as the log might not be empty when a drive ships. So for 5 entries on average we have about 50 days of 0% failure probability (as the log fills up to its 256 boundary), then a 20% chance of failure on day 51. The chances of a drive being still alive after that are thus 80%. On day 102 there is also a 20% chance of failure, making a total chance of 64% for a drive being alive on day 102 (it has two 20% chances to die until then). And so on. Given 5 log entries on average over one year, the failure probability would be 79%. For 3 log entries on average over one year, the failure probability would be 80.2%.

I'm wondering whether Seagate can really say with confidence that "[b]ased on the low risk as determined by an analysis of actual field return data, Seagate believes that the affected drives can be used as is." (see KB article).

Edited by Oliver.HH, 29 January 2009 - 08:46 AM.

### #1062 jaclaz Posted 29 January 2009 - 09:33 AM

jaclaz

The Finder

• Developer
• 16,627 posts
• Joined 23-July 04
• OS:none specified
• Country:
@Gibby
@Oliver.HH

What I was trying to say here:
http://www.msfn.org/...o...092&st=1048
was that if certain events are logged "in pairs" or in "triplets", the actual probabilities would lessen a bit.

Take as an example the "normal" XP Event Log, you usually get when booting NT based systems a :
6009 - Microsoft ® Windows ® 5.01. 2600 Service Pack 2 Multiprocessor Free.
6005 - Event log service was started

And a:
6006 - Event log service was stopped
when switching off.

In "normal" power cycle of a (highly ) hypothetical install where no errors, no warnings, nor other notifications are logged, the entries would be always in triplets.

To get to 320 in such a system, the "initial" address x would have to be x+3*n=320 as a function of n power cycles, i.e. only values satisfying x=320-3*n, from the bottom:

317 as opposed to 319 - 318 -317
314 as opposed to 316 - 315 -314
311 as opposed to 313 - 312 -311
....

thus reducing the probabilities to 1/3 of what calculated for the "single event" addition.

Absolutely. That's in line with what I intended to point out. While the probability of anything failing is 100% in an infinite number of years, these drives are very likely to fail in their first year of service. My calculation estimates a 76% chance of failure within a year. Real numbers might be even worse.

Here is a simple graph for first 12 months (assumed as being 30 days each, using working days of course will flatten the curve):

I see it more like gambling on a coin throw:
Everytime you switch the thing on you throw a coin, on average for the first six months you will win, besides being not at all what one is supposed to do with data, gambling beyond six months, where percentage gets to 50.6% is betting money on an "unfair" game.

jaclaz

### #1063 Oliver.HH Posted 29 January 2009 - 10:51 AM

Oliver.HH
• Member
• 7 posts
• Joined 28-January 09

To get to 320 in such a system, the "initial" address x would have to be x+3*n=320 as a function of n power cycles, i.e. only values satisfying x=320-3*n, from the bottom:

317 as opposed to 319 - 318 -317
314 as opposed to 316 - 315 -314
311 as opposed to 313 - 312 -311
....

thus reducing the probabilities to 1/3 of what calculated for the "single event" addition.

That's certainly true for the chance of hitting when you are near the boundary. But if you consider that you are approaching the boundary with three times the speed and there is always a next boundary to hit (initially at 320, then at every multiple of 256), you are getting close to those boundaries three times as often.

In the long run, that amounts to 1/3 (chance of hitting when near) * 3 (frequency of being near the boundary) = 1, so the overall probability would be the same.

Thanks for the graph! Should help people decide whether to participate in the game ;-).

### #1064 Gradius2 Posted 29 January 2009 - 11:33 AM

IT Consultant

• Member
• 240 posts
• Joined 16-January 09
• OS:Windows 7 x64
• Country:

Now lets just do a simple google search, by entering:

"Seagate 7200.11 failing": I got 72,100 links

Sorry to say so , but that's not really a "valid" argument, as I (and some other people) see it :
http://homepages.tes...ess-metric.html

jaclaz

That study is based from 2005~2007 datas, if google wants to keep on the top of search engine, they should always make better filters to avoid repetitive links.

Perhaps they're already doing better than the past (they should), but I know, I cannot trust such engine for metric, it was just a simple and speculative example.
"Two things are infinite: The Universe and Human stupidity; and I'm not sure about the Universe." Albert Einstein

### #1065 Laz Posted 29 January 2009 - 12:29 PM

Laz

Newbie

• Member
• 29 posts
• Joined 11-January 09

@Gibby
@Oliver.HH

What I was trying to say here:
http://www.msfn.org/...o...092&st=1048
was that if certain events are logged "in pairs" or in "triplets", the actual probabilities would lessen a bit.

Take as an example the "normal" XP Event Log, you usually get when booting NT based systems a :
6009 - Microsoft ® Windows ® 5.01. 2600 Service Pack 2 Multiprocessor Free.
6005 - Event log service was started

And a:
6006 - Event log service was stopped
when switching off.

In "normal" power cycle of a (highly ) hypothetical install where no errors, no warnings, nor other notifications are logged, the entries would be always in triplets.

To get to 320 in such a system, the "initial" address x would have to be x+3*n=320 as a function of n power cycles, i.e. only values satisfying x=320-3*n, from the bottom:

317 as opposed to 319 - 318 -317
314 as opposed to 316 - 315 -314
311 as opposed to 313 - 312 -311
....

thus reducing the probabilities to 1/3 of what calculated for the "single event" addition.

Absolutely. That's in line with what I intended to point out. While the probability of anything failing is 100% in an infinite number of years, these drives are very likely to fail in their first year of service. My calculation estimates a 76% chance of failure within a year. Real numbers might be even worse.

Here is a simple graph for first 12 months (assumed as being 30 days each, using working days of course will flatten the curve):

I see it more like gambling on a coin throw:
Everytime you switch the thing on you throw a coin, on average for the first six months you will win, besides being not at all what one is supposed to do with data, gambling beyond six months, where percentage gets to 50.6% is betting money on an "unfair" game.

jaclaz

it seems to explain why there was a rash of failures beginning a few months ago during the summer then more reciently, as people who powered their system twice a day ( in the morning and evening) compared to those who like myself, tended to power on once a day and left it on and got almost twice the usage.

### #1066 jaclaz Posted 29 January 2009 - 02:07 PM

jaclaz

The Finder

• Developer
• 16,627 posts
• Joined 23-July 04
• OS:none specified
• Country:

That's certainly true for the chance of hitting when you are near the boundary. But if you consider that you are approaching the boundary with three times the speed and there is always a next boundary to hit (initially at 320, then at every multiple of 256), you are getting close to those boundaries three times as often.

In the long run, that amounts to 1/3 (chance of hitting when near) * 3 (frequency of being near the boundary) = 1, so the overall probability would be the same.

Still, not entirely my point, it's a bit hard to explain myself.

the 1/3, in the hypothetical system depicted, makes things a bit different depending on values with which the initial counter is set in factory.

First 3 "critical values" are:
• 320 =(320*0+256)
• 576 =(320*1+256)
• 832 =(320*2+256)

Since 320 cannot be divided by 3, IF the counter is initially set to 0, AND all logs are made in three entries, you have 0% probabilities to hit 320, as
106*3=318 (n=106)
and
107*3=321 (n=107)

next occurrence is 256 steps away, but since 320+256=576 can be divided by 3, you have 100% probabilities (read certainty) to hit 576 (with n=192), and so on.

If the counter is intially set to 1, you have 0% probabilities to hit 320, as well as 0% probabilities to hit 576, but you will hit 832 with (with n=277)

If the counter is intially set to 2, you have 100% probabilities to hit 320, (with n=106)

If the counter is initially set to 3, same as if it were set to 0, only first hit will come at corresponding n-1: 192-1=191

...and so on.

Of course, just as in the case of a single event log per power cycle (where if you started with value 319 you were dead on first shot), if you start with 317 you are dead, but if you start with 319 you have 171 chances before hitting next "critical value".

Best value to start with is 1 with which you have 277 cycles, but starting with 4, 7, 10 .... will only lessen your cycle life by 1 , 2, 3, etc.

If you are unlucky and start with 2, you have only 106 cycles......

Roughly the difference between 3 and 9 months of "life".

If the logs are written sometimes in triplets, sometimes in couples, sometimes in single "lines", I don't think there is a way to calculate probabilities, but however the probabilities should be lower than what calculated for all single "lines".

jaclaz

### #1067 DrDisk Posted 29 January 2009 - 02:35 PM

DrDisk
• Member
• 3 posts
• Joined 24-January 09
I'm not mathmatician however I think it is safe to say it is split 50/50. The half of the people that have the problem and the other half that do not!

Allen

### #1068 Oliver.HH Posted 29 January 2009 - 02:56 PM

Oliver.HH
• Member
• 7 posts
• Joined 28-January 09

Still, not entirely my point, it's a bit hard to explain myself.

OK, I hope now I've got it !

You're saying that there are certain logging patterns, which might decrease the probability of hitting the critical counter values, right?

If so, I'd say, it's entirely possible, though unlikely that such patterns exist. But certainly, we cannot know for sure.

If there is some variance in the number of log entries written per power cycle, the probability of drive failure should be along the curves already presented. The lesser the average number of log entries, the higher the chance of failure, but the overall magnitude does not change much.

On another topic: I happen to own a Dell OEM drive (ST3500620AS). It currently runs Dell's OEM firmware DE12. Dell has issued an updated version DE13 to address the Barracuda bug, but the update's batch file calls the updater's executable with a parameter "-m BRINKS". In contrast, Seagate's SD1A firmware update for that drive is called "MOOSE...". What happens if the Dell folks inadvertently published the wrong version and I incorrectly apply a BRINKS firmware to a MOOSE drive? Will it just stop working or will it get even worse (silently and slowly altering data, for example)?

### #1069 dlethe Posted 29 January 2009 - 11:04 PM

dlethe

Newbie

• Member
• 10 posts
• Joined 18-January 09
Many of you are still making outrageous statements about the depth of the problem. Try getting the exact number of 7200.11 disks seagate shipped rather than relying on a previous post that takes my 1,000,000,000 annual drive forecast for 2014 and dividing by 3 as a starting point. You will find that the actual number of 7200.11s is much smaller.

Secondly, consider that only some of the disks with the same firmware are affected, and that the failure isn't due to mechanical failure. This means the secret sauce relies on something that happened to SOME of the disks either in QC or as part of the manufacturing process. One can independantly deduct this by considering that you have to give seagate the serial number. So think about how many QC test stations there are on the floor and consider that it is more likely that only one of them was configured to leave the trigger code on the disks.

The anger at Seagate (and me for daring to put things in perspective) is misguided. As I posted on the storagesecrets.org site,
"So, as they say, I feel your pain. A “lot” of people are having this issue? Millions? I don’t see Dell, HP, SUN, IBM, EMC, and Apple making press releases about how Seagate burned them. You don’t think apple would drop Seagate in a heartbeat if they felt Seagate had a real-world, high-risk problem? Not to say any particular manufacturer is more in-tune with their customer base than others … but do you think Apple or anybody else would have signed with Fujitsu by now if this was a problem that they were concerned with?

Sorry to be so blunt, but can’t you concede that if there was a large-scale risk that was even a fraction of the AFR of disk drives due to head crashes and component failure that the PC vendors wouldn’t be setting up major programs to do damage control with their customers? It isn’t happening. The only way to explain the quiet from the PC vendors is that the risk is profoundly low.

The dirty little secret — Disk vendors tell their top customers about such issues almost as soon as they find them. It is likely everybody knew about it. Put 2 + 2 together and ask why there is no story among the PC vendors, and why nobody jumped from Seagate."

So all of these other vendors HAD to have known about the problem from the beginning. It would not be unreasonable for them to also receive the complete lists of affected serial numbers (But I am not saying they were given the list as fact, it is my opinion that they were given lists of the affected drives that Seagate shipped them).

========
Now for something else ... all you 7200.11 owners, to help counteract the flames many of you sent me in privacy or online somewhere .. i am not some stealth P/R firm hired by Seagate. Here is a nice little post that shows you that the 7200.11 disks you all have are "rated" for only 2400 hours use per year. http://storagesecret...usage-annually/. These disks are desktop disks and were never designed for 24x7 use, or even high duty. Even though I have some myself, I use them as part of a RAID group, so when one of them dies I will just replace it. if any of you have non-RAIDed (RAID with parity, not RAID0) 7200.11s, then you need to make sure you backup often.

Edited by dlethe, 29 January 2009 - 11:07 PM.

### #1070 tontano68 Posted 30 January 2009 - 12:29 AM

tontano68
• Member
• 2 posts
• Joined 30-January 09
Hello:
I am new here and am wondering if anyone from Canada is here? I have this exact same problem everyone is having, but this time, Seagate tells me to contact HP, as its a problem with HP and not related to Seagate.

HP then tells me, they will ship another HD (did not specify which one...wonder why)

Now the important thing is to get the data back. Some data recovery services are asking anywhere between \$1000 - 1500.

You guys are great here, and it looks like several choices are available.

My question is (base don the 2 types of issues with the 72000.11):

How do I know which problem I have. The only thing my HDD does and not boot up. It worked up until this morning, and after a reboot, got stuck at "Boot System Failure", when I ran a diagnostics, it did not find the "HDD".

Also would the HD doctor mentioned here come with both hardware and software.

Any help would be appreciated.

Thanks
Tony

Edited by tontano68, 30 January 2009 - 12:47 AM.

### #1071 poolcarpet Posted 30 January 2009 - 01:31 AM

poolcarpet

Member

• Member
• 107 posts
• Joined 02-January 09
dlethe,

few things that i'd like to point out:

1. majority of people here ARE those affected by this problem. that means working today, reboot, and it goes poof.
2. majority of the people here, when contacting Seagate, was told that there were no problems and to send in the drive for RMA. for data recovery please pay. it has since changed, as seagate is now admitting a problem with the hard disk and has asked people to update firmware and contact them for free recovery (incidentally, has anyone actually got their drives repaired for FREE??)
3. it doesn't matter if the problem affect hundreds or thousands or millions of hard disks. what matters is we have 100+ people from all over the world reporting this problem. we are not even talking about those who just RMA-ed their drives thinking it's a 'real' hardware fault. i personally know a friend who just RMA-ed the drive didn't expecting it to be a firmware problem. i agree that 100+ is very small, but the fact that it happened around the same time, plus there must be tons of people out there who just RMA-ed or returned the drives (see news about how certain stores are CLEARING OUT the 7200.11 with deep discounts??) so the 100+ could be just the tip of the iceberg. no one will ever know exactly how many disks were affected, except seagate themselves and i'm 100% sure they will NEVER disclose that info.
4. for you to come in here and defend seagate, it's just plain stupid - especially if you are not paid by them, and you are disclosing your info and business. please do yourself and your future paychecks a favour, and stop coming in here to defend Seagate. NO ONE here has any good opinions of seagate after how they dealt with us and banned us from their forums.
5. if you wish to defend seagate, i suggest you do it in your storagesecrets AND believe me when i say this - do it in the seagate forums. not only will people be more receptive to you, the seagate moderators would probably love you to death.
6. your statements about none of the other major vendors making press releases - don't you think if they really encounter this problem, it will be much better for them to settle this quietly with seagate. why would they want to make a big fuss out of this and THREATEN their own PC/notebook sales? you think people will buy HP/Dell/Apple/<insert whatever brand name here> if that company went public to complain about Seagate OEM disks which they use in their PC/notebooks giving THIS problem?
7. also, do you know which pc/notebook vendors are using the 7200.11 F/W SD15 in their products?? how do you know that they are using this 7200.11 problem batch or a more stable 7200.10 batches? if they are not using 7200.11 F/W SD15, don't you think that explains the lack of this problem with the major PC/notebook vendors??
8. your statement about 2400 hours use per year - i can fully accept it if the disks start to show more bad sectors, or start to have read/write problems when they are used beyond the 2400 hours but for it to just disappear on next reboot??? surely that 2400 hours has got nothing to do with this problem. besides, 2400 hours is equal to 100 days. we have people whose hard disks failed LESS than 100 days. still a valid point then??

just believe me when i say this - i don't see why anyone would disclose their identify and company, and come out to defend seagate with no clear benefits to themself/their company. as someone mentioned before, you are just giving yourself and your company a black eye by doing that.

Many of you are still making outrageous statements about the depth of the problem. Try getting the exact number of 7200.11 disks seagate shipped rather than relying on a previous post that takes my 1,000,000,000 annual drive forecast for 2014 and dividing by 3 as a starting point. You will find that the actual number of 7200.11s is much smaller.

Secondly, consider that only some of the disks with the same firmware are affected, and that the failure isn't due to mechanical failure. This means the secret sauce relies on something that happened to SOME of the disks either in QC or as part of the manufacturing process. One can independantly deduct this by considering that you have to give seagate the serial number. So think about how many QC test stations there are on the floor and consider that it is more likely that only one of them was configured to leave the trigger code on the disks.

The anger at Seagate (and me for daring to put things in perspective) is misguided. As I posted on the storagesecrets.org site,
"So, as they say, I feel your pain. A “lot” of people are having this issue? Millions? I don’t see Dell, HP, SUN, IBM, EMC, and Apple making press releases about how Seagate burned them. You don’t think apple would drop Seagate in a heartbeat if they felt Seagate had a real-world, high-risk problem? Not to say any particular manufacturer is more in-tune with their customer base than others … but do you think Apple or anybody else would have signed with Fujitsu by now if this was a problem that they were concerned with?

Sorry to be so blunt, but can’t you concede that if there was a large-scale risk that was even a fraction of the AFR of disk drives due to head crashes and component failure that the PC vendors wouldn’t be setting up major programs to do damage control with their customers? It isn’t happening. The only way to explain the quiet from the PC vendors is that the risk is profoundly low.

The dirty little secret — Disk vendors tell their top customers about such issues almost as soon as they find them. It is likely everybody knew about it. Put 2 + 2 together and ask why there is no story among the PC vendors, and why nobody jumped from Seagate."

So all of these other vendors HAD to have known about the problem from the beginning. It would not be unreasonable for them to also receive the complete lists of affected serial numbers (But I am not saying they were given the list as fact, it is my opinion that they were given lists of the affected drives that Seagate shipped them).

========
Now for something else ... all you 7200.11 owners, to help counteract the flames many of you sent me in privacy or online somewhere .. i am not some stealth P/R firm hired by Seagate. Here is a nice little post that shows you that the 7200.11 disks you all have are "rated" for only 2400 hours use per year. http://storagesecret...usage-annually/. These disks are desktop disks and were never designed for 24x7 use, or even high duty. Even though I have some myself, I use them as part of a RAID group, so when one of them dies I will just replace it. if any of you have non-RAIDed (RAID with parity, not RAID0) 7200.11s, then you need to make sure you backup often.

### #1072 dlethe Posted 30 January 2009 - 01:38 AM

dlethe

Newbie

• Member
• 10 posts
• Joined 18-January 09
No, you don't have the exact same problem. You have symptoms of a dead disk drive. The problem could be anything from media failure to bad power supply, chip failure, SATA interface failure, bad cable. That is big point of my earlier posts. People think the boot-of-death issue is root cause for 7200.11 drive failures. How do you find out? You ask (or pay) for a failure analysis. There is no way to know for sure root cause for a failure such as yours where nothing is returned unless you do a post-mortem .. unless you have a lot of equipment at your house and know how to use it.

Anyway, you can probably get much better pricing for data recovery services. Perhaps under \$500. Some services will tell you what is wrong and will quote you recovery price for free, once you send them the disk. If price is too high, then you pay postage and they return it to you.

### #1073 poolcarpet Posted 30 January 2009 - 01:38 AM

poolcarpet

Member

• Member
• 107 posts
• Joined 02-January 09
hi tony,

these 2 threads has the details on how to fix this - IF AND ONLY IF your hard disk is suffering from this BSY and 0 LBA problem.

http://www.msfn.org/...howtopic=128807
http://www.msfn.org/...howtopic=129263

You'll need to get those RS232 components to connect to your hard disk to check.

Good luck!

Hello:
I am new here and am wondering if anyone from Canada is here? I have this exact same problem everyone is having, but this time, Seagate tells me to contact HP, as its a problem with HP and not related to Seagate.

HP then tells me, they will ship another HD (did not specify which one...wonder why)

Now the important thing is to get the data back. Some data recovery services are asking anywhere between \$1000 - 1500.

You guys are great here, and it looks like several choices are available.

My question is (base don the 2 types of issues with the 72000.11):

How do I know which problem I have. The only thing my HDD does and not boot up. It worked up until this morning, and after a reboot, got stuck at "Boot System Failure", when I ran a diagnostics, it did not find the "HDD".

Also would the HD doctor mentioned here come with both hardware and software.

Any help would be appreciated.

Thanks
Tony

### #1074 jaclaz Posted 30 January 2009 - 02:54 AM

jaclaz

The Finder

• Developer
• 16,627 posts
• Joined 23-July 04
• OS:none specified
• Country:

You're saying that there are certain logging patterns, which might decrease the probability of hitting the critical counter values, right?

If so, I'd say, it's entirely possible, though unlikely that such patterns exist. But certainly, we cannot know for sure.

If there is some variance in the number of log entries written per power cycle, the probability of drive failure should be along the curves already presented. The lesser the average number of log entries, the higher the chance of failure, but the overall magnitude does not change much.

Yep .
All in all, I would say that most probably chances are a bit lower than what initially estimated, but still in the same order of magnitude.

Many of you are still making outrageous statements about the depth of the problem. Try getting the exact number of 7200.11 disks seagate shipped rather than relying on a previous post that takes my 1,000,000,000 annual drive forecast for 2014 and dividing by 3 as a starting point. You will find that the actual number of 7200.11s is much smaller.

Just for the record, my previous post took "your" 1,000,000,000 and divided it, for several reasons, by several factors:
3 (maybe current production)
3 (maybe number of drives in the "family")
1.1 (rounding by defect)=>at this stage the number of drives in the possibly "affected" family is 100,000,000, i.e. 1/10 of "your" 1,000,000,000
10 ("safety factor")=>at this stage the number of drives in the possibly "affected" family is 10,000,000, i.e. 1/100 of "your" 1,000,000,000
500=1/0.002 (to take into account Seagate statement)

(3*3*1.1*500*10)=49,500

i.e. 1,000,000,000/49,500=20,202 => 20,000

In other words, the hypothesys is that throughout 2008 Seagate manufactured between 10,000,000 and 100,000,000 drives of the "family".

Then, the lower number is taken and multiplied by the smallest possible incidence of "affected drives" (per Seagate statement) 0.002, i.e. that 1/500 of the drives in the family may be affected.

Since "some percentage" can mean ANY number <1, the found 20,000 can easily come out by a lesser number of drives "in the family" manufactured multiplied by a higher percentage:
10,000,000*0.002=20,000 (1/500)
5,000,000*0.004=20,000 (1/250)
2,500,000*0.008=20,000 (1/125)
1,000,000*0.02=20,000 (1/50)
while still within the same definition of "some percentage", and at the lower end of it......

Without official data, and as clearly stated, the above numbers are just speculative, and, while they might be inaccurate, the order of magnitude seems relevant enough to rule out that the 100÷150 reports here on MSFN, represent NOT a significant fraction (1/7 or 1/8) of all affected drives.

jaclaz

Edited by jaclaz, 30 January 2009 - 02:54 AM.

### #1075 Keddar Posted 30 January 2009 - 03:15 AM

Keddar
• Member
• 4 posts
• Joined 10-January 09

*Snip the braying and neighing of barnyard animals.*
The anger at Seagate (and me for daring to put things in perspective) is misguided. As I posted on the ONE MONTH OLD site,
...
*Snip more animal sounds.*

Now for something else ... all you 7200.11 owners, to help counteract the flames many of you sent me in privacy or online somewhere .. i am not some stealth P/R firm hired by Seagate...
*Snip.*

Now, see, I just plain don't like you because you come across as a pompous scumbag figurehead.

Maybe if your "website" was more than a month old and filed with something recognizable as more than elaborate filler material, I'd think more of you and your "credentials." Maybe if it was hosted by a company that put more than ads into their WHOIS data. Maybe if you didn't constantly belittle the amount of effort put into this problem by CONSUMERS regardless of the outright failures and lies of the Seagate PR department.

Who knows - maybe I'm just too picky when it comes to people. I'd like to think that people who'd post on this topic would either be people afflicted with the problem, owners of hardware they are concerned will soon fail, or people trying to help by posting constructive information - not people that site there and link to their month old depository of Seagate handjobs at EVERY POSSIBLE CHANCE.

So either you're being paid or you hope to be paid.

Also, make up your mind. You say on your site, and I quote, "...ships 10,000,000 Barracuda disk drives a month..." - and yet you chide jaclaz for his numbers. Your 120,000,000 drives a year and his 111,111,111 drives a year are remarkably similar, don't you think? Actually, your number is higher. Huh.

You estimate a 1:65,536 chance at failure. You honestly think there's only about 1,800 drives that will ever be affected by this issue? Seagate wouldn't even have an intern look at a problem that small, let alone stonewall for months, release firmware updates, and offer free data recovery. They'll end up spending a lot more than the \$10,000 they made selling those drives.

Anyways.

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users