Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral

About dlethe

  1. 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.
  2. 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 dont see Dell, HP, SUN, IBM, EMC, and Apple making press releases about how Seagate burned them. You dont 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 cant 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 wouldnt be setting up major programs to do damage control with their customers? It isnt 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://storagesecrets.org/2009/01/failure-...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.
  3. Come on, I told you all you need to know except the diagnostic bit pattern, and the offset for the 16 or 32-bit number that must be saved in the offset at the moment the drive is powered down that creates the bricking effect. Do you want that too? (Nobody has part of this info, for obvious reasons, but if you search the web, you can find reference to the magic number. Somebody at the TH site posted it yesterday (So if you want to do some detective work go for it). The most you got from anybody else is a convoluted problem with firmware, which made it look as if everybody is vulnerable. Why do you think Seagate wants serial numbers to see if the disk is a candidate for the problem? If the firmware rev was the only factor, then all you would need is the date code to see if you have a vulnerable disk. Seagate would also be able to write an active-x plug-in to let people test their disk drives online. Instead you have to run a windows EXE and give them your serial number. Common sense is if problem was easy to identify, then they wouldn't go to all the effort to require users to run an executable. It would take all of an hour to write a plug-in to ID the disks. Use some common sense here, factor in how many 'cudas that Seagate ships in a year, and tell me how many millions of disk drives SHOULD be failing if this is a firmware bug that affects all disks running this particular firmware. Seagate is on a 5-year run rate to ship 1,000,000,000 disk drives ANNUALLY by 2014. If the drive problem was as big as you say it is, then they would have caught it in QC. The problem is a purple squirrel (sorry about the yankee slang -- it means incredibly rare). If the bricking issue is as big as you claim to be, then EMC, Dell, IBM, HP, Arrow, Apple, and all the others would have made press releases saying they were signing Fujitsu a long time ago. Where are these press releases? Now here is the dirty little secret. High volume direct customers get bug reports in advance of firmware releases. Draw your own conclusions whether or not you believe consumer-oriented companies such as Apple are more interested in keeping seagate than their devoted customer base. Would Seagate dare to NOT tell Apple, Dell, HP what is going on? Unlikely. Would Apple take such a risk? Less likely? Would Apple and the others assess the risk to their customer base knowing full details and determine that the number of affected disks is statistically insignficant? You tell me. I am sorry that I have not told you all that I know. Frankly, I have better things to do. It is just that this consipiracy nonsense has gone too far, and somebody has to set the record straight. Off to work, I have a company to run now.
  4. Nope, I actually write disk testing software for storage subsystem manufacturers. I do not sell any hardware, or do I sell 3rd-party software. On rare situations, I fix disk drives for friends and families, but my company only does data recovery for certain RAID controllers that lose their metadata. We do not fix or repair disk drives. Metadata recovery is something different. HP has purchased almost 100,000 CDs of a consumer-oriented diagnostic that they bundle with business class PCs, which puts things in perspective. I've written firmware for RAID controllers, and dozens of companies slap their names on RAID configurators that I wrote. I published one of the first S.M.A.R.T. diagnostic products back in 1998, but it really didn't ship until 1999. (I think it was the first that supported SCSI, but can't prove it. here is a writeup by a Ziff Davis from the web archive about that package that was written almost 10 years ago http://web.archive.org/web/20010219010850/...2391076,00.html Heck, some of the manufactures call me when they have certain problems, and a fair number of OEMs VARs, and people in the disk drive testing business (like some who process RMAs for Dell) use my code. So enough about me, Have I earned at least a little bit of credibility? (P.S. I don't mean to be arrogant, and I apologize if I have presented myself in that way. Rather I wish to point out that I do know what I am talking about, and well, chances are good that I'm the big dog here when it comes to disk technology). http://www.santools.com is my company, and I wrote vast majority of the code.
  5. Steve: Respectfully ... are you nuts?? Send it to seagate or some other company that will fix this for you. (Of course it may be a moot point now, as you have possibly tampered with the disk too much and destroyed the replacement warranty). It costs you nothing but return postage for them to tell you exactly what is wrong, and if it really is the bricking problem, they may fix it for free (some people report this, I can not confirm or deny). If the problem is something else then you can't fix it yourself anyway .. unless you have a bunny suit, a clean room, and a half-million dollars worth of equipment.
  6. Arnd, your statement will only prove to be correct if the true number of bricked drives due to this problem is "significant". My contention is that the odds of this happening are remote .. incredibly remote. Perhaps when/if there is a lawsuit, you will see a study of how many disks Seagate took on RMA that had confirmed bricking incidents. Furthermore, you said that Seagate should be aware this this was not to be expected failures? Well, duh, bugs are never expected. If they were expected they wouldn't be bugs. If they were aware of the bugs they would fix them. Speaking from perspective of a former firmware architect. This was a nasty thing to track down and probably took thousands of man-hours to diagnose. Give them some credit for putting enough manpower on the problem so it was diagnosed and fixed so quickly. Furthermore, you have no idea what bugs there are in other models of disk drives, many are much worse, some have 100% guarantee of data destruction. I know, I have the NDA reports and won't tell you any more ... except that the number of people who have this problem, due to the nature of the chain-of-events that must lead up to the event, is rather small compared to other issues. Trust me, there isn't a disk drive or raid controller, or any product in the marketplace that is 100% bug-free. That is why people buy redundant hardware and make backups. You can get all "ignited" over the issue, but I rather vent my dissatisfaction with Microsoft. Look at the fear out there. You have a previous poster showing us pictures of his rigging of the serial port for a drive that may or may not be bricked ... no telling how much money he has spent. Odds strongly favor his problem has nothing to do with the firmware. If this issue wasn't so hyped up, perhaps he would have sent it to seagate who would have fixed it for free if it was a bricking problem, or at least they would quote him a repair price before he spent all of this time risking making the problem worse. People think because they have a dead drive, that it is due to a massive firmware bug that afflicts 30%-40% of the seagate disks out there, according to a certain lawfirm. Give me a break. no way. If the problem was that prevalent, then it would have been caught in test in a matter of minutes. P.S. As for removing posts, I do not know the contents of the deleted posts. If the posts had inaccurate information about Seagate that was stated as fact, then Seagate should remove them. At the very least it degrades the value of the forum, especially when people google those specific posts looking for some answers. Bad/inaccurate info must always be removed for benefit of who comes in the future. What if it turned out that the problem was due to a bad motor? I wouldn't want to come to the Seagate site some time in the future and waste my time looking for a firmware update. Conversely, if Seagate removed posts due to a little public relations work, then I agree with you, the posts should have stayed. (Providing they had some inherent value to the forum. If the posts were complaints and rants from somebody who had a mechanical disk drive that didn't survive the warranty period, then I can forgive deleting it
  7. The obvious question comes to mind .. how do you know your disk suffers from boot-of-death, and not something like a circuit board failure or massive head crash?
  8. How many people actually have a bricked drive due to a firmware bug vs. disks that died due to the traditional mechanical problems??? I don't know, do you know? In any event the storagesecrets.org blog posted the Seagate 24x7 emergency data recovery telephone number, so you can contact them right now and chew them a good one. I'm not saying they don't deserve it, but if you want to find out what seagate is going to do to fix your disk, seems to me best way to find out is to call the data recovery people and ask them directly. As for how do you know this won't happen again -- get real. Nobody knows. The only certainties in life are death & taxes
  9. The 7200.11 problems are being hyped all out of proportion. Seagate just released full details of the issue to OEMs. It is not anything like people are reporting it to be. Problem tied to certain test equipment and junk that it left on reserved areas of disk. More details on link below: http://storagesecrets.org/2009/01/seagate-...-overhyped-fud/
  10. Seagate is now addressing the issue big time. They have online tool to see if your disks are affected, they provide warranty replacements, as well as a fix. Problem is a firmware bug. Specifics on affected model and serial numbers; downloads; and end-user options are at: Info on Seagate 7200.11 brick problems (Revised) The link above is a copy of the Seagate site with live links, so you can currently click on it to run their validator, even though the original link from the first article is dead. Screenshot of Seagate's tool that verifies at least this disk is affected, so at least we know Seagate is reporting *some* affected drives http://storagesecrets.org/2009/01/seagates...destined-brick/