Home > Disk Drives, Failure Analysis > Seagate boot-of-death analysis – nothing but overhyped FUD

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

January 25th, 2009 Leave a comment Go to comments

The nature and scope of the Seagate 7200.11 boot-of-death problem has been blown way out of proportion, and people are making grossly incorrect assumptions.  Seagate recently released a failure analysis report under non-disclosure to some (or all, I don’t know) OEM partners and distributors that describes the issue in great detail. Why under NDA? In my opinion, full knowledge of the problem could potentially create a blueprint for virus writers who want to go beyond just erasing files on targeted machines. So to be safe, full specifics aren’t being disclosed (but you can now find a little more info on Tom’s Hardware if you know where to look). 

As part of the manufacturing process,  Seagate writes diagnostic information to reserved areas of the disk drives.  These bit patterns work with the test equipment and drive firmware to perform diagnostic actions such as placing it in a secure lockdown mode Once SATA disks (well, all disks) are powered up, they maintain counters in these reserved areas for purposes of diagnostics and usage reporting.  Reserved areas are used because they are non-volatile, are hidden from the O/S, and require special commands to read/write to them. The firmware includes error-recovery logic that is triggered based on the contents of log page values. [Example, when drive temperature gets to high, the disk spins down].

So here is what happened. For whatever reason, some of Seagate’s test equipment didn’t zero out the test pattern once the test suite completed, and these disks were shipped.  When disks that have this test pattern pre-loaded into the reserved area, and put into service, they are subjected to certain errors, warnings, or I/O activity [remember, I’m not going to tell you what the specific trigger is …, but the information is available to people who need to know] that results in a  counter reaching a certain value. (This is NOT a threshold, but an exact value.  I.e., if the magic number was 12345, then 12346 and higher would NOT trigger the bricking logic.  Only 12345 triggers it. ).  Furthermore, this value is stored in a circular buffer, so it can go up and down over the life of the disk.  In order for the disk to brick, the disk must be spun down at the EXACT MOMENT this field is set to this magic number.  (The magic number is not an 8-bit value, either).  So either on power-down, or power-up, the firmware saw the bit pattern, and the magic number in the circular buffer, and likely did what it was programmed to do … perform a type of lockdown test that is supposed to happen in the safety of the manufacturing/test lab, where it can be unlocked and appropriate action taken by test engineers.

So, let’s say you have a disk with the naughty firmware, that was tested on the wrong test systems at the wrong time.  Let’s say that the magic number is a 16-bit number.  Then even if you had one of the disks that are at risk, then the odds are > 65,000:1 that you will power the disk off when the counter is currently set to this magic number. If the magic number is stored in a 32-bit field, then buy lottery tickets, because you have a higher probability of winning the lottery then you do that the disk will spin down with the register set to the right value.  (BTW, the magic number is not something simple like number of cumulative hours.)

What also happened is that everybody and their brother who ever had a non-related problem like a general drive failure on a Barracuda disk has been coming out of the woodworks complaining about the problem. They see posts about bricking & boot-of-death, and next thing you know they are adding fuel to the fire that got picked up by media.   Remember, that people who don’t have problems generally don’t log into Seagate support sites.

Common Questions and Anwers

Q.  So why doesn’t Seagate just post an alert saying if you have certain firmware, your disk is in danger of bricking?
A. Unless your disk was hooked up to the test equipment in question, then there is no danger.  The reserved area must already contain the magic bit pattern.

Q. Will a firmware update fix the problem, really?
A. Yes, too many things have to fall into place for the bricking function to kick in, so the update merely has to add further constraints, or clear out reserved area.

Q. Will the boot-of-death destroy data?
A. No, but you have to either hook your disk up to a diagnostic board (approx $500, or send it back to Seagate, who will fix it for free. )

Q. What about those reports where 30-40% of disks are affected?
A. 3-40% disks have affected firmware.  30-40% of the disks were not tested on affected hardware. 30-40% of disks will not encounter the specific condition of reaching the specific bricking value in a certain log page.  So do the math and consider the source.  While the statement may be true concerning affected firmware, once you factor in everything else, then the risk is “nominal”.

Q. Are patches / fixes out yet?
A. Yes. As of the date of this posting, they are out for every affected model.  The problem, of course, is that it is a pain to update the firmware.

Q. Do I need to update my firmware?
A. I don’t know. See if you have an affected serial number.

Q. What are some of the caveats?
A. None, really, unless you are running Windows.  If your affected disks are installed in a Solaris, IRIX, HP/UX, or any UNIX-based system, or if the disk(s) are behind a RAID controller, then you need to get out your screwdrivers.  (For what it is worth, I’m testing some code which will allow you to flash the revised firmware on UNIX platforms.  Feel free to contact me if you are interested.

  1. Brian
    January 18th, 2010 at 01:34 | #1

    I unfortunately have to agree with a number of posts that Seagate’s quality level with the Barracuda series of drives (SATA) is less than optimal. I have experience with both OEM channel drives and consumber channel drives. Both have exhibited high failure rates. In the OEM channel, both Gateway (MPC) systems and Dell systems that shipped with 7200 RPM 250 GB and 7200 RPM 500 GB drives have had issues. With some of the drives, fortunately in a SATA RAID1 configuration, one of the drives would report as “missing” by the RAID software on system power up. I say fortunately, because when the drive finally fails, the user’s system can still be recovered from the still functioning drive. I don’t have the hard numbers in front of me right now, but I have replaced over a dozen of these hard disk drives over a couple hundred systems. That is a much higher rate than one in 65,000. I have a Dell system on my desk that came with a RAID 1 configuration with two Seagate 500 GB drives, one of them just failed on a system reboot. It is a hard failure, and I will replace it under warranty. I went to the Seagate site and checked it for a firmware update, and it does not have one. I have had a number of other Seagate 250 GB Barracuda drives begin to exhibit very high seek errors and ECC correctable errors. These error counts are in the neighborhood of 1 to 4 MILLION errors per drive when tested with Gibson Research’s SpinRite 6 software, running in Mode 2. I unpacked a 250 GB drive that was in it’s factory shipping container, and tested it with SpinRite, and it too had 1.4 MILLION errors. This is a brand new drive that had never been power cycled. I test Western Digital hard disk drives with this same software, in the same systems, and get ZERO errors. I take suspect Seagate drives to different systems, just to be sure that the environment (controller, motherboard, power supply, etc.) is not contributing to the issue, and the results are the same. Very high error rates that are not dependent on the system it is being tested in. A symptom that seems to accompany the failing drives if they have been in service is a complaint from the user that the system is slow. Testing the drive seems to bear the bad news that the drive is on it’s way out, and high seek errors will manifest itself as a slow system. I have imaged several of these drives over to Western Digital hard disks, and the systems are faster to boot, which is expected because the Western Digital drives do not exhibit the seek errors and ECC correctable errors. At home, I tested the fourth drive from Seagate belonging to the Barracuda 7200 series, today, and it was horrible. This is all a string of replacements from Seagate for a drive purchased roughly 18 months to 2 years ago. Two of the replacements in this string were “refurbished” from Seagate. Seagate, to their credit, has been really good about issuing an RMA for the drives. They were very slow to ship this last one, and after a call to them, they indicated that they were out of stock of the affected drive.
    Now, concerning Maxtor 160 GB DiamondMax 9 series drives… don’t get me started.

  2. Mick Tisell
    September 23rd, 2009 at 13:20 | #2

    Another unsatisfied Seagate owner here. Purchased the now infamous “ST3500320AS” drive in June 2008 (just search Seagate’s own forums for 1000’s of posts regarding failures), in August 2009 completely out of nowhere tons of I/O errors started happening without any warning. Within 2 days the drive was completely non-responsive and only showing up in the BIOS sometime. Had to put the drive into ziploc bags and then freeze a solid block of ice inside another ziploc bag around the drive and was able to recover almost all of my data. Seagate just sent me a replacement which I will be putting though some severe stress tests and then only using as a spare drive. I will NEVER purchase anything with Seagate or Maxtor labels on it EVER AGAIN! I will also ensure that every chance I get to make a post about Seagate quality I will do so.

  3. NoName4U
    August 14th, 2009 at 15:55 | #3

    I have used 4 Seagate HDDs,ST3500641AS, for the last 4+ years in a ReadyNAS NV box without any problems.

    I recently decided to upgrade the HDDs for more space.
    I went with 4 x ST31500341AS.

    After ~10 DAYS one of them started to have a steadily increasing number if Reallocated Sectors as reported by SMART.

    I RMA-ed ALL of the drives !!!

    I got 4x WD1002FBYS instead.

    DO NOT bother with these extremely poor designed HDDs from Seagate.
    They suck extremely BAD.
    Your comment regarding this problem being _simply_ FUD has, unfortunatelly, NO shred of reality!

    Get a grip !


  4. Joko
    July 21st, 2009 at 15:05 | #4

    My 500gb 7200.11 bsy-ed yesterday, after 7 months from purchase.
    So 7-9 months is the highest i’ve seen, a lot more are below this,
    and alot more will folow and you can bet on that.

    You missed some maths classes didn’t you. Yet you make some bold calculations and probably expected this amount of responce.

    Me and my brothers.

  5. Dirk
    April 8th, 2009 at 06:30 | #5

    I have a feeling these drives will go brick mode on people for YEARS to come. I bought two of the Seagate’s 500GB affected drives (ST3500320AS with SD15 firmware) summer of 2008 and the first one vanished from BIOS 8 months after purchase and the second one 5 weeks after the first one (this morning in fact). I didn’t even know about the whole firmware disaster until now. Suffice to say the next HDD I buy won’t be a Seagate.

  6. Tuomo
    March 24th, 2009 at 12:01 | #6

    Well I bought two 500GB Seagates on last August and got one to my work computer at University. One of mine and the one in work computer have died…

    2/3 so far…

  7. Chris
    March 11th, 2009 at 16:17 | #7

    Funny… I got myself 2 ST3750330NS (that’s the 750GB ES.2 – which is SUPPOSED to be a “high availability drive” *lol*) about 4 months ago and *poof* both of them became victim of this Bug today…
    If your calculation was even close to truth, how can you explain this (and all the other bricked drives from the comments here)? A “> 65,000:1” chance and I hit it twice? At the same time? Very realistic calculation…

  8. David
    February 18th, 2009 at 13:19 | #8

    I have to say I find this article hard to accept. My hard drive is now failed with this issue. It lasted a whole of 4 months. I bought a new machine replacing a system with a Western Digital in it. That drive had lasted 8 years. For me the failure rate is 100%. Worse yet I’ve never even heard of this issue unitl now, after my drive has failed. I simply do not believe that the chances are in 1 in over 65000. That means I have to belive that Seagate would have had to sell over 650K of these things to have even 10 people experience the problem. Regardless of what the truth is, I will be getting a Western Digital drive to replace the failed Seagate. I’m not going to live with the uncertainity of a Seagate drive failing again. They had a chance to win me as a customer and blew it big.

  9. Seahate
    February 12th, 2009 at 22:31 | #9

    I have Seahate HDD, which was defect in 2 weeks. After fixing with 500 USD equipment, it brake again in 3 days! BIOS do not recognize. Waiting for Seahate to get my data out and give me another, not defect HDD (where I do not need to do any firmware update).

  10. FilipM
    February 5th, 2009 at 03:53 | #10

    Danny :
    What? “odds are > 65,000:1??

    As I was thinking about throwing dices, I just flashed my ST3500320AS SD15 with SD1A : SUCCESS
    Serial 5QM2SJ3M
    P/N: 9BX154-303

    The drive was functional before as it is now. I noticed improved boot times since the upgrade.

    I used the fw available today ( 5feb ) MooseDT-SD1A-2D-8-16-32MB.ISO on an M2N-E mobo (MCP55). The only drives attached were the affected one and the DVD drive(PATA).
    I believe it is important to follow the EXACT advice at the end of the flash, that is to power down the drive IMMEDIATLY instead of soft reboot.
    Good luck.

  11. jcsjcm
    February 4th, 2009 at 07:13 | #11

    Well I have to say 100% of the drives fail. I’ve purchased 2 in the past month and both failed. One lasted a little over 4 weeks and the other lasted a total of 6 hours. First boot up and it was crashed! How can you boost my confidence that the failure rate is as low as you state and it would take a miracle to brick this hard drive. I am petrified when I receive my replacement (I couldn’t get a refund on one of them due to it being 3 days over the 30 day money back guarantee) from seagate. I would have preferred Seagate contacting me that they would not be giving me back a refurb that is affected by this boot of death syndrome! First drive was 750gb and the second was 500gb. Sounds like they have a bigger problem than you are stating!

  12. Braadworst
    February 3rd, 2009 at 06:09 | #12

    Seagate has updated their website with new ES.2 firmware at last.


    But be warned ….. don`t fix it if it ain`t bricked ….. yet.

  13. H8 Seagate
    January 30th, 2009 at 18:30 | #13

    “The nature and scope of the Seagate 7200.11 boot-of-death problem has been blown way out of proportion, and people are making grossly incorrect assumptions.”

    You don’t know WTF you’re on about.

  14. Braadworst
    January 30th, 2009 at 13:48 | #14

    8 days ago i send a request to discsupport@seagate.com for a firmware upgrade.

    No response.

    They could at least send me a notification of receiving my request + assuring to send me the new firmware soon.

    The new firmware for my ST3500320NS ES.2 is not afailable from their website.

  15. Danny
    January 29th, 2009 at 12:54 | #15

    What? “odds are > 65,000:1”? Are you serious? First off who are you and how would you have insight to what seagate technicians themselves have been keeping hush hush?

    This problem is affecting a huge amount of hard drives and not just the 7200.11. I have a 7200.11 with the same issue and recently sent it to Seagate. Seagate makes great drives and the warranty is bar none. This is a major problem but from what I am seeing they are going to address the problem.

  16. sieve-x
    January 28th, 2009 at 16:36 | #16

    Hello David. I guess saying ‘overhyped FUD’ and ‘under NDA’ in a forum
    loaded of users with affected drives was like lighting fireworks in
    a gas station and some got you wrong. I think the number behind all
    affected models is something only Seagate may really know for sure.

    Did you have any success with SMART log pages for checking if specified
    data pattern is present ? That may allow someone to code a tool for veryfing if a particular drive is effectively affected by the issue
    and maybe even changing event counter/pattern to a safe value until
    new firmware is applied (it would be useful because in many cases like
    RAID controllers its not feasible to do a live -UNIX- firmware update).


    • January 29th, 2009 at 01:29 | #17

      Understood, but I can’t tell everything I know, I don’t have permission to do so. In grand scheme of things people don’t need to know the exact bytes involved. Rather knowing what has to happen to brick a disk is much more important. Before I spoke up there were ridiculous rumors about 30% of the disk drives, and, well, getting redundant.

      I never officially said what LOG pages, offsets or reserved areas are involved, so don’t make me reveal that. I am not confirming or denying anything relating to the specifics that might get me a subpoena :) I really wanted to start on it, but had other priorities.

      You can NOT change SMART event counters, even if you wanted to. I am pessimistic that detecting a pre-brickable drive is worth the effort. Even if I knew exactly what had to be done, I would have to test my theory by bricking a drive. I don’t have that much of an interest other than intellectual curiosity.

      As for flashing disk drives behind RAID controllers … I wrote a RAID configurator back in 2000 that let you flash FC disks behind a mylex (LSI RAID controller) under IRIX, Solaris, LINUX, AIX … Piece o’ cake if you know the internals. I can do a live Solaris update of Seagate 7200.11 firmware now behind a LSI RAID controller in JBOD mode, and know I could get it to work if the disk was part of a virtual (RAID) drive if somebody was going to pay me to do it for them .. I don’t have any takers yet to warrant the time on something I don’t need.

  17. anonymous
    January 28th, 2009 at 08:24 | #18

    David said, “This whole “conspiracy” doesn’t pass the smell test.”

    I agree people – you should never assume conspiracy over incompetence, especially at storagesecrets.org.

  18. Vinícius Ferrão
    January 27th, 2009 at 12:21 | #19

    Awesome and my drive is in this list.

  19. SL
    January 26th, 2009 at 19:02 | #20

    So how much did Seagate Pay you? Seagate has known about this problem SINCE SEPT 2007, and did NOTHING. So stop trying to sugar coat things.
    Ask the larger channel partners how many drives they’ve gotten back.

    3:9QM6****:ST3500320AS:9BX154-303:SD15:N/A:N/A:KRATSG:2008-12-05:2008-12-19:N/A:DerSnoezie:Netherlands:(no detect in bios):
    5:9QM3****:ST3500320AS:9BX154-568:SD81:08464:2008-05-20:KRATSG:2008-08-01:2008-12-23:N/A:ToKuRo:Chile:(no detect in bios):
    29:5QM1****:ST3500320AS:9BX154-303:SD15:08383:2008-03-24:WUXISG:2008-07-01:2009-01-02:N/A:waly2k1:Argentina:(no detect in bios):
    30:9QM5****:ST3500320AS:9BX154-303:SD15:09063:2008-08-11:KRATSG:2008-07-01:2008-12-25:N/A:criverock:Italy:(no detect in bios):
    33:9QM*****:ST3500320AS:9BX154-303:SD15:08371:2008-03-15:KRATSG:2008-05-07:2008-12-29:N/A:KillerB:Korea:(no detect in bios):
    37:9QM1****:ST3500320AS:9BX154-303:SD15:08364:2008-03-11:KRATSG:2008-05-01:2008-12-12:OEM:taa:Russia:(no detect in bios):
    38:9QM6****:ST3500320AS:9BX154-303:SD15:09096:2008-08-12:KRATSG:2008-09-01:2009-01-07:OEM:kiave:Poland:(no detect in bios):
    39:9QM0****:ST3500320AS:9BX154-303:SD15:08315:2008-02-06:KRATSG:2008-03-31:2009-01-11:N/A:laz:Canada:(no detect in bios):
    40:9QM6****:ST3500320AS:9BX154-303:SD15:09082:2008-08-24:KRATSG:2008-12-01:2009-01-11:OEM:SeaGAYBarracuTARD:Canada:(no detect in bios):
    42:9QM8****:ST3500320AS:9BX154-303:SD15:09174:2008-10-28:KRATSG:2008-11-14:2008-01-11:OEM:harwin:Singapore:(no detect in bios):
    46:9QM1****:ST3500320AS:9BX154-303:SD15:08337:2008-02-22:KRATSG:not sure(at least 1 year old):N/A:OEM:harwin:Singapore:fine:
    47:9QM6****:ST3500320AS:9BX154-303:SD15:09085:2008-08-27:KRATSG:2008-09-30:2009-01-11:N/A:bp2411:UK:(no detect in bios):
    49:9QM5****:ST3500320AS:9BX154-303:SD15:09062:2008-08-10:KRATSG:2008-04-09:2008-12-01:OEM:prim:Spain:(no detect in bios):
    50:5QJ0****:ST31000340AS:9BX158-303:SD15:08516:2008-06-26:WUXISG:2008-11-13:2009-01-14:RETAIL:Karlston:Australia:(no detect in bios):
    51:5QJ0****:ST31000340AS:9BX158-302:SD04:08185:2007-11-07:WUXISG:2008-04-06:2008-06-21:RETAIL:hallwal:USA:(0GB reported):
    52:9QM8****:ST3500320AS:9BX154-303:SD15:09167:2008-10-24:KRATSG:2008-12-01:2009-01-11:OEM:s1lencer:Malaysia:(no detect in bios):
    53:9QJ0****:ST31000340AS:9BX158-303:SD15:09012:2008-07-06:KRATSG:N/A:N/A:OEM:rimask:Singapore:(no detect in bios):
    54:9QK0****:ST3750330AS:9BX156-303:SD15:09024:2008-07-15:KRATSG:2008-11-28:2008-12-30:OEM:valdas:Lithuania:(no detect in bios):
    55:9QJ1****:ST31000340AS:9BX158-303:SD15:08526:2008-07-03:KRATSG:2008-08-01:N/A:OEM:me0w:Sweden:fine:Debian GNU/Linux
    56:9QJ1****:ST31000340AS:9BX158-303:SD15:08526:2008-07-03:KRATSG:2008-08-01:N/A:OEM:me0w:Sweden:fine:Debian GNU/Linux
    57:5QJ0****:ST31000340AS:9BX158-303:SD15:08524:2008-07-01:WUXISG:2008-08-01:N/A:OEM:me0w:Sweden:fine:Debian GNU/Linux
    58:9QM4****:ST3500320AS:9BX154-303:SD15:08525:2008-07-02:KRATSG:2008-08-01:N/A:OEM:me0w:Sweden:fine:Debian GNU/Linux
    59:9QM1****:ST3500320AS:9BX154-303:SD15:08345:2008-02-27:KRATSG:2008-03-30:N/A:OEM:me0w:Sweden:fine:Debian GNU/Linux
    60:5QJ0****:ST31000340AS:9BX158-303:SD15:09133:2008-09-29:WUXISG:2009-01-01:N/A:OEM:jkc120:USA:fine:FreeBSD 7.1
    61:5QJ0****:ST31000340AS:9BX158-303:SD15:09133:2008-09-29:WUXISG:2009-01-01:N/A:OEM:jkc120:USA:fine:FReeBSD 7.1
    61:5QJ0****:ST31000340AS:9BX158-303:SD15:09133:2008-09-29:WUXISG:2009-01-01:N/A:OEM:jkc120:USA:fine:FReeBSD 7.1
    62:9QM7****:ST3500320AS:9BX154-303:SD15:09116:2008-09-18:KRATSG:2008-11-25:2009-01-13:N/A:DeadST3500320AS:USA:(no detect in bios):
    63:9QJ1****:ST31000340AS:9BX158-303:SD15:09107:2008-09-12:KRATSG:2008-11-01:2009-02-01:OEM:SSKEV:Greece:(no detect in bios):
    64:9QM5****:ST3500320AS:9BX154-303:SD15:09077:2008-08-22:KRATSG:2008-08-30:2009-01-10:N/A:D3m3nt0r:Germany:(no detect in bios):
    67:9SZ*****:ST3320613AS:9FZ-162-300:SD11:08391:2008-03-29:TK:2008-08-01:2008-12-22:OEM:kadolf:Germany:(0GB reported):WinServer 2k8 x64
    68:9QM2****:ST3500320AS:9BX154-303:SD15:08381:2008-03-22:KRATSG:(unsure):2009-12-01:N/A:AlexLilic:Sweden:(no detect in bios):N/A
    72:9QM1****:ST3500320AS:9BX154-303:SD15:08366:2008-03-13:KRATSG:Spring08:2008-12-01:RETAIL:idshark:Germany:(no detect in bios):Linux:BeQuiet750W
    73:9QM4****:ST3500320AS:9BX154-303:SD15:08481:2008-05-31:KRATSG:2008-06-27:2009-01-15:N/A:sunne2k:Spain:(2100GB report in linux):linux kernel 2.6.24-21
    74:9QM6****:STM3500320AS:9BX154-303:SD15:09083:2008-08-25:KRATSG:2008-11-12:2009-01-16:OEM:Schoolisoutfan:Germany:(no detect in bios):Vista Business 64Bit: Antec 430W
    75:5QM1****:ST3500320AS:9BX154-303:SD15:08386:2008-03-27:WUXISG:2008-07-15:N/A:Roonster:Germany:STILL WORKS FINE
    76:5QJ0****:ST31000340AS:98X158-335:SD15:09036:2008-07-24:WUXISG:2008-11-04:N/A:Roonster:Germany:STILL WORKS FINE
    77:9QM2****:ST35000320AS:9BX154-303:SD15:08381:2008-03-22:KRATSG:2008-04-30:N/A:OEM:TerTop:MY:fine:WinXP_x86_x64:NMB 460W
    78:9QM8****:ST3500320AS:9BX154-303:SD15:09165:2008-10-22:KRATSG:2008-12-15:2009-01-03:OEM:mahk:Germany:BIOS hung:XPPRO32/Linux2.6.xx:HEC300W
    79:9QJ1P***:ST31000340AS:9BX158-303:SD15:09075:2008-08-20:KRATSG:N/A:2009-01-15:OEM:Coltrane69:U.S.:No Detect In Bios
    80:5QM2****:ST3500320AS:9BX154-303:SD15:09105:2008-09-10:WUXISG:2008-10-21:NOT YET:OEM:bigjimmcbob:CANADA:file:DSN-323(Linux based):N/A
    81:90j1****:ST31000340AS:9BX158:SD15:08527:2008-07-04:KRATSG:2008-08-01:2009-01-15:OEM:chrisbkr:USA:(no detect in bios):WinVista:650W
    82:9QM6****:ST3500320AS:9BX154-303:SD15:09075:2008-08-20:KRATSG:2008-09-01:2009-01-18:OEM:bertm:Netherlands:(no detect in bios):N/A:N/A
    83:9QM6****:ST3500320AS:9BX134-505:SD25:09085:2008-08-27:KRATSG:2008-10-01:2008-01-03:RETAIL:wirefall:Germany:0GB:Win XP Home:500W
    84:5QJ1****:ST31000340AS:9BX158-303:SD15:09127:2008-09-26:WUXISG:2008-10-15:2008-01-18:OEM:donnerzusel:Germany:Failed after firmware upgrade recommended by Seagate to AD14:Linux 2.6.28:Enermax PRO82+ 425W
    86:5QJ0****:ST31000340AS:9BX158-303:SD15:09056:2008-08-07:WUXISG:2008-11-01:2009-01-18:N/A:aalexandre:Russia:(no detect in bios):winXP:N/A
    87:9QM3****:STM3500320AS:9GT154-325:MX15:08401:2008-04-05:KRATSG:2008-10-30:2009-01-18:RETAIL:sellig:FRANCE:(not detected in bios):XP pro:N/A
    88:9QK0****:ST3750330AS:9BX156-303:SD15:08495:2008-06-11:KRATSG:2008-07-01:2009-08-14:OEM:Gradius2:Chile:POST error (it recognize, but returns error on POST):Vista Ultimate SP1 x64:N/A
    89:9QK0****:ST3750330AS:9BX156-303:SD15:09023:2008-07-14:KRATSG:2008-08-10:2009-08-14:OEM:Gradius2:Chile:BSY error:Vista Ultimate SP1 x64:N/A
    90:9QK0****:ST3750330AS:9BX156-303:SD15:09023:2008-07-14:KRATSG:2008-08-10:2009-08-14:OEM:Gradius2:Chile:BSY error:Vista Ultimate SP1 x64:N/A
    93:9QK0****:ST3750330AS:9BX156-303:SD15:080542007-08-07:2008-12-15:KRATSG:2009-01-10:OEM:Tristano:ITALY:(not detected in bios):N/A:N/A
    97:5QJ0****:ST31000340AS:9BX158-303:SD15:09115:2008-09-17:WUXISG:2008-11-20:2009-01-19:OEM:JRD393:USA:(no detect in bios):XP Pro:Corsair 650W
    98:9QM6****:ST3500320AS:9BX154-303:SD15:09105:2008-09-10:KRATSG:2008-11-07:N/A:OEM:winicjusz:Poland:fine:Vista x64 Business:BeQuiet 450W
    99:9QM6****:ST3500320AS:9BX154-303:SD15:09105:2008-09-10:KRATSG:2008-11-07:N/A:OEM:winicjusz:Poland:fine:Vista x64 Business:BeQuiet 450W
    100:9QM3****:ST3500320AS:9BX154-303:SD15:08406:2008-04-10:KRATSG:2008-11-20:2009-01-22:RETAIL:ili:Israel:(no detect in bios):Vista64:620W
    101:9QM69WY2:ST3500320AS:9BX154-303:SD15:09085:2008-08-27:KRATSG:2008-09-10:2009-01-18:OEM:geff44:France:(no bios detect):Ubuntu 8.10:480W Advance
    102:9QM1****:ST3500320AS:9BX154-303:SD15:08357:2008-03-07:KRATSG:2008-N/A-N/A:2009-01-03:RETAIL:709394hk:HongKong:BSY:XP Pr
    103:9QM1Z***;ST3500320AS;9BX154-303;SD15;08367;2008-06-08;KRATSG (Not detected in BIOS) Canada, British Columbia, Surrey

  20. Billy Goats
    January 26th, 2009 at 16:20 | #21

    So, who’s astro-turfing for Seagate here? Spreading FUD?
    I think Seagate makes some decent server drives (SAS) but come on, they slipped up (obvious guilt in a firmware patch was created, and the hoops an individual has to jump through to get firmware patched) and are taking the “legal department’s advice” to the letter.

    Don’t forget Momentus Firmware 7.01…and the damage it did to hundred’s of users files…

    • January 26th, 2009 at 17:08 | #22

      I strongly agree with you when I say that they should make the firmware easier to get. The reason they don’t, BTW, is that upgrading firmware can make a mess of things, particularly if you have an OEM drive. Firmware updates can clear configurable parameters and cause compatibility problems, even catastrophic data loss. It is a last resort type of thing … at least for ATA/SATA disks.

      As for FUDing, or astro-turfing for seagate? Sorry, I have no finanical interest or obligation with Seagate. My motivation is mostly because I have seen way too many posts from people re-hashing the same story, and it just doesn’t make sense that any compay that ships 10,000,000 Barracuda disk drives a month could possibly have a problem of this magnitude w/o Apple, Dell, IBM, and the others dropping Seagate as a vendor because they have millions of customers with dead disk drives.

      This whole “conspiracy” doesn’t pass the smell test.

  21. Vinícius Ferrão
    January 26th, 2009 at 12:31 | #23


    1:65536 ratio?

    I just be kidding. I’m one affected with this infamous issue, and you say FUD? Came on… just see the facts ok? A lot of people getting the same issue.

    I’ve managed to fix my drive because I have some experience with hardware and with knowledge base of MSFN Foruns.

    When your data appears to be lost due a freaking firmware issue I’ll shout to you: overhyped FUD.

    I hope this comment will not be under heavily moderation.

    • January 26th, 2009 at 14:22 | #24

      The magic number is > 255, therefore it is not an 8-bit field. Therefore it must be 16 bits or more. If the field is 16-bits then there are 2^16 possibilities. Ergo, 65536:1. The field is also not a sequential counter. I recognize that the standard deviation may well favor some numbers more than others, so odds may be higher than stated. If the magic number was 1,0,or FFh, or FFFFh, then one could assume a non-uniform distribution. It isn’t one of those numbers.

      As for fixing your drive. Great. Glad to hear it. Maybe you had the problem. I am not saying you didn’t. I am writing that the odds favor it was something else.

    • January 26th, 2009 at 14:42 | #25

      P.S. Go to the “S.M.A.R.T.” page. Read the study of 100,000 disk drives by google. They posted the 3-month through 5-year mortality rates of ATA disks with varying temperature and degree of loading. This will give you an idea how common (unfortunately) drive failures are. I’ve lost data too … a little more than 10 years ago I lost an important disk drive. As a result I got into writing S.M.A.R.T. software & diagnostics for HP-UX and Windows ’95 (or was it 3.1, don’t remember).

      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.

  22. remblues
    January 26th, 2009 at 12:12 | #26

    Regardless of whether the “real” risk of bricking is overblown, from a typical consumer’s perspective (i.e., someone who doesn’t know what “firmware” is), Seagate’s response has been atrocious.

    Here’s my experience:

    “Unless your disk was hooked up to the test equipment in question, then there is no danger.”
    But how can one know without waiting for the drive to brick? Should I wait until the warranty runs out? If I have a drive which *might* have been hooked up to that test equipment in question, Seagate should make sure the drives’ firmware is upgraded. As the link above shows, they are refusing to do this — or, more accurately, they are only providing the means for sophisticated PC users to do this, and only if such users have access to a desktop PC.

    • January 26th, 2009 at 14:26 | #27

      The only way to know if you have a suspect disk is to check the serial number via the online tool. Unfortunately Seagate doesn’t programmatically log test information. Theoretically somebody may dump the various SMART log pages and go through at least part of the reserved area and look for the markers. I have a pair of these disks that have the serial numbers that indicate they are at risk. I may do some digging tonight and dump them. If I figure out a mechanism to tell if a particular drive has something fishy in one of the reserved places that I can get to without hooking the disk up to the test bench, then I will let you know.

  23. John
    January 26th, 2009 at 09:57 | #28

    You make it sound like the problem is very rare yet there have been plenty of people who have successfully de-bricked their drives using the procedures found elsewhere (e.g. http://www.msfn.org/board/index.php?showtopic=128807)

    Most drive failures do not result in the drive not appearing in BIOS so the idea that many people who think they have hit the bug are actually experiencing typical drive failures does not make sense – the symptoms are fairly unique for this problem.

  24. anonymous
    January 26th, 2009 at 09:09 | #29

    Q. Are patches / fixes out yet?
    A. Yes. As of the date of this posting, they are out for every affected model. The problem, of course, is that it is a pain to update the firmware.

    Correct A.:
    No, they are not… Se this post by Seagate forum moderator AlanM:

  1. January 26th, 2009 at 04:04 | #1
  2. January 26th, 2009 at 11:24 | #2
  3. February 3rd, 2009 at 02:18 | #3
You must be logged in to post a comment.