Nowdays? Not much. I do think they come out of different factories, and have different characteristics... but I'm pretty sure that the higher capacity maxtor drives are really just rebranded seagate.
This is why the same exact firmware issue affected both Seagate Barracuda and ES drives... AND Maxtor Diamondmax drives.
I'm not here to explain what *should* happen to to lick boots of those that have been wronged; I'm here to try and explain what *has* happened and *why* things are the way they are.
Make your choices as you will. I'm just trying to help get some much needed information out that can't seem to make it through 'proper' channels.
Also Here is a list of affected models. If our drive is on that list, and has the SD* firmware, it's affected. It is that simple.
As for service issues - the facts are thus: Phone is slammed to the point of breaking. Email is slammed and every 'firmware request' is being dumped in a queue for a mass email as soon as they have a good working one to five out. Web-Chat is slammed to capacity.
They simply do not have enough trained people in place to help everyone, and they cannot just hire nosepickers off the street to help with this situation (both due to skill requirements, and budget reasons - if you hadn't noticed, there's not much money to spread around these days)
I'll say this, I have seen the numbers, and less then 1% of drives RMA'd happen in years 4 and 5. The cut back of warranty was mostly an economical one due to the current state of things, we don't have to keep replacement drives around as long which saves crazy amount of costs, and we can use that warehouse space for replacement externals (which fail 10x more often then internals - more single points of failure by their nature) and other reasons. Kinda sucks, but with such warranties, there are collateral costs involved that a company can afford in times of comfort that they cannot in times of lean.
And yeah, I understand your frustration. Thank you for the compliments!
Thank you for that clarification. I knew it had to do with the internal configuration of the drive, but wasn't sure about the details. I figured they were pretty family specific, and could vary even with the same model number.
that article on MSFN is about the best reference I've seen yet - I am really not familiar with working on drives via a serial interface, though I may pick one up cheap and low capacity off eBay and play around! I know of no special commands more then that article describes. however, I'll look around and see if I can get that information (though I don't know how much I can disclose if I do find it.). We'll see what I can dig up.
Also, I cannot say for sure it's EXACTLY 320 entries. That was the number bandied about the most reliably - but I'll double-check and see if I can't get a more accurate number. Perhaps you can write a quick utility that will zero out that log file?
I'm a geek, same as everyone here. I know how we geeks operate when it comes to information, and seeing the backlash, I understand exactly why this is happening - a concept I don't think most people of management or sales background really understand.
Overall though, I really just want to help out the community that's supported me through many, many problems. This is one of the rare cases in which I am in a rare and unique position to use what I know to give back as much help as I've gotten over the years and benefit a whole lot of people. And if that saves my company that provides me a lifestyle I enjoy from going under as easily.. well, sometimes it's good to break a few rules for the greater good.
Also, it makes my job easier keeping all your really smart brains away from me in a job context!:D
If the flash utility will flash the drive at all(even if the data is inaccessible), then you have a very good chance of restoring functionality to the drive with an older or the new 'good' firmware yet to be published.
Then yeah, if you don't care about warranty, then PCB replacement would be your best bet i think (other then data recovery). Match up part number and firmware revisions though!
There are windows programs that will do such tests.. otherwise in linux you can just "dd if=/dev/random of=/dev/ count=1" or something like that (I can't remember exactly the commands to end the dd at the end of the drive), and just run your SMART check after the drive's finished being written to. Then do the same and zero it out (/dev/zero instead of/dev/random) and check again. this will obviously wipe any data on the drive, of course, so don't do it on a drive that you care about the data, as it won't be there afterwards.
And a whole lot more people are sitting with bricked drives and inaccessable data because they didn't wait a few extra days to design a good procedure for dealing with the influx of people and drives. 3 or 4 days wouldn't have made much of a difference, (especially since this issue has apparently been around for months anyways) and would have avoided many dozens of people losing access to their drives that were working fine beforehand.
There is a set of part numbers that it regularly bricks, but I don't have access to the details why and what just yet. When I do, I'll try to update with details.
I do know that swapping the PCB won't help a firmware bricked drive as the firmware is not kept on the PCB - it's kept on the drive itself mostly.
Are your drives recognized in the BIOS? If so, then better to just wait until they have the good firmware. If not, then wait until they have the process in place for returning the drives for a physical firmware flash.
The drives have to go through a calibration and burn-in as part of the manufacture process, which should have already detected any bad sectors and reallocated them and then the SMART zero'ed out before going into the field. It's always a possibility that a few sectors were just on the tipping point and weren't detected during burn-in or later went bad for other reasons.
Having a few reallocated sectors like that is a pretty consistant event across all drives, no matter then make, model or manufacture date or location. It may indicate failure, but your best bet would be to do a zero-wipe on the drive or some other heavy write operation over the disk a few times and see if that number grows significantly. If it does, replace it.
OEM drives like that often have a special firmware designed by the OEM themselves based on Seagate's stock firmware.
It may or may not have the problem, but all the OEMs have been given details about this issue and are responsible for checking their firmware and updating it as necessary.
As far as I know, no. There may be a way using the controller some people have posted instructions on building, but your best bet would be just to watch the KB article like a hawk and update the firmware as soon as a good release is out.
Sorry, I was using "One in a Million" as more of an expression then a valid statistic.:) But yeah, your math adds up, though actual field results I'm sure are much lower. 30% of 14 million drives(the number of drives potentially affected) is 4.2 million - we'd be overran with dead drives.
Yeah. I have no idea what's going on with the forum. I don't work directly with AlanM but I imagine he has a set of policies he has to enforce, and that sucks for doing actual dev work on the forums.
The forums are known as dangerous waters for support people to venture in, and forbidden to do so in any official capacity as support agents. But we do read them, especially when things go crazy like this.
You can ask that a CD be mailed to you with the firmware flash on it. We don't publicize it, but we already do that with our normal drive software. So if you absolutely can't go to a friend's house, download and burn the ISO and flash it that way, usually the agent is happy to send you a CD in the mail. If not, ask for a team lead and they'll do it.
The log, if my information is correct, is written each time a SMART check is done. This will always happen on drive init, but can also happen at regularly scheduled events during normal usage, as the drive has to go through various maintenance functions to keep it calibrated and working properly.
The problem with the undetectable bios drives really isn't new. Your customer service knew it for a long time, but they are paid so little and probably have such strict procedures that they don't care about Seagates customers and no one dared to report the drive failures as a major incident. Everyone shut up about it and the people which are responsible and do care only learned about it months later when (or shortly before) it got out to the press.
----
You say that as though it was willful ignorance on the part of the front line support. It really wasn't - most of the time the agents work as far as they can, and if the issue isn't fixable to them, they have to stop and recommend RMA. You will never have a front line agent talk you through hooking up an interface controller serially and issue ATA command instructions to the drive... it's simply out of the scope of support. They rely on people higher up to look at the data and go 'we have a 30% return rate (number pulled out of my ass as an example!) - lets engage QA and find out why!" - until the point that someone from QA or management steps in and goes "We've isolated this issue - here's what it is and here's how to fix it"
Now, a few of them take it on themselves to keep an eye out for issues like this, and actually work on the problem - but most stay within their scope of support and leave it to those who are supposed to be looking out for this kinda thing to do their jobs. Like I said earlier in this thread though, we get too many "problems" that are one-off issues, that it wouldn't surprise me if this was honestly overlooked in a form of group cognitive dissonance as people couldn't comprehend that an issue could have slipped through that would affect so many drives.
I have no idea where the breakdown occurred, but once the issue was isolated, I'm sure there was a managerial OHSHI- and they made them re-prove it... and then someone made a bonehead decision (which is pretty typical and of no surprise to me) to release a public statement without having developed a clear procedure on how to deal with it.
Slashdot Mirror
Not sure - but it sounds very, very close to how the issue was described to me, therefore I believe it's authenticity.
Mod Up, Please!
The SD1A is the firmware that was being pushed out supposed to *fix* the stuttering and bricking issues.
However, it was pulled from the KB article as it was bricking some of the 500Gb drives worse then the original problem it was pushed out to solve.
See the actual article these commends are tagged onto for details.
Nowdays? Not much. I do think they come out of different factories, and have different characteristics... but I'm pretty sure that the higher capacity maxtor drives are really just rebranded seagate.
This is why the same exact firmware issue affected both Seagate Barracuda and ES drives... AND Maxtor Diamondmax drives.
And I'm glad to help!
I'm not here to explain what *should* happen to to lick boots of those that have been wronged; I'm here to try and explain what *has* happened and *why* things are the way they are.
Make your choices as you will. I'm just trying to help get some much needed information out that can't seem to make it through 'proper' channels.
Also Here is a list of affected models. If our drive is on that list, and has the SD* firmware, it's affected. It is that simple.
As for service issues - the facts are thus: Phone is slammed to the point of breaking. Email is slammed and every 'firmware request' is being dumped in a queue for a mass email as soon as they have a good working one to five out. Web-Chat is slammed to capacity.
They simply do not have enough trained people in place to help everyone, and they cannot just hire nosepickers off the street to help with this situation (both due to skill requirements, and budget reasons - if you hadn't noticed, there's not much money to spread around these days)
This is life. Welcome to it.
I'll say this, I have seen the numbers, and less then 1% of drives RMA'd happen in years 4 and 5. The cut back of warranty was mostly an economical one due to the current state of things, we don't have to keep replacement drives around as long which saves crazy amount of costs, and we can use that warehouse space for replacement externals (which fail 10x more often then internals - more single points of failure by their nature) and other reasons. Kinda sucks, but with such warranties, there are collateral costs involved that a company can afford in times of comfort that they cannot in times of lean. And yeah, I understand your frustration. Thank you for the compliments!
Thank you for that clarification. I knew it had to do with the internal configuration of the drive, but wasn't sure about the details. I figured they were pretty family specific, and could vary even with the same model number.
that article on MSFN is about the best reference I've seen yet - I am really not familiar with working on drives via a serial interface, though I may pick one up cheap and low capacity off eBay and play around! I know of no special commands more then that article describes. however, I'll look around and see if I can get that information (though I don't know how much I can disclose if I do find it.). We'll see what I can dig up.
Also, I cannot say for sure it's EXACTLY 320 entries. That was the number bandied about the most reliably - but I'll double-check and see if I can't get a more accurate number. Perhaps you can write a quick utility that will zero out that log file?
I'm a geek, same as everyone here. I know how we geeks operate when it comes to information, and seeing the backlash, I understand exactly why this is happening - a concept I don't think most people of management or sales background really understand.
Overall though, I really just want to help out the community that's supported me through many, many problems. This is one of the rare cases in which I am in a rare and unique position to use what I know to give back as much help as I've gotten over the years and benefit a whole lot of people. And if that saves my company that provides me a lifestyle I enjoy from going under as easily.. well, sometimes it's good to break a few rules for the greater good.
Also, it makes my job easier keeping all your really smart brains away from me in a job context! :D
If the flash utility will flash the drive at all(even if the data is inaccessible), then you have a very good chance of restoring functionality to the drive with an older or the new 'good' firmware yet to be published.
Then yeah, if you don't care about warranty, then PCB replacement would be your best bet i think (other then data recovery). Match up part number and firmware revisions though!
*laughs*
I just thought it sounded like a cool nickname.
DRAT! My carefully laid plans have been revealed!
This is just my ploy to get you to buy Maxtor DiamondMax drives instead! :D
CURSES! *shakes fist*
There are windows programs that will do such tests.. otherwise in linux you can just "dd if=/dev/random of=/dev/ count=1" or something like that (I can't remember exactly the commands to end the dd at the end of the drive), and just run your SMART check after the drive's finished being written to. Then do the same and zero it out (/dev/zero instead of /dev/random) and check again. this will obviously wipe any data on the drive, of course, so don't do it on a drive that you care about the data, as it won't be there afterwards.
And a whole lot more people are sitting with bricked drives and inaccessable data because they didn't wait a few extra days to design a good procedure for dealing with the influx of people and drives. 3 or 4 days wouldn't have made much of a difference, (especially since this issue has apparently been around for months anyways) and would have avoided many dozens of people losing access to their drives that were working fine beforehand.
1% of 14 Million is still 140,000 drives dead.
I'll see what I can dig up!
People are reporting good results with that method though.
There is a set of part numbers that it regularly bricks, but I don't have access to the details why and what just yet. When I do, I'll try to update with details.
I do know that swapping the PCB won't help a firmware bricked drive as the firmware is not kept on the PCB - it's kept on the drive itself mostly.
Are your drives recognized in the BIOS? If so, then better to just wait until they have the good firmware. If not, then wait until they have the process in place for returning the drives for a physical firmware flash.
The drives have to go through a calibration and burn-in as part of the manufacture process, which should have already detected any bad sectors and reallocated them and then the SMART zero'ed out before going into the field. It's always a possibility that a few sectors were just on the tipping point and weren't detected during burn-in or later went bad for other reasons.
Having a few reallocated sectors like that is a pretty consistant event across all drives, no matter then make, model or manufacture date or location. It may indicate failure, but your best bet would be to do a zero-wipe on the drive or some other heavy write operation over the disk a few times and see if that number grows significantly. If it does, replace it.
OEM drives like that often have a special firmware designed by the OEM themselves based on Seagate's stock firmware.
It may or may not have the problem, but all the OEMs have been given details about this issue and are responsible for checking their firmware and updating it as necessary.
As far as I know, no. There may be a way using the controller some people have posted instructions on building, but your best bet would be just to watch the KB article like a hawk and update the firmware as soon as a good release is out.
Sorry, I was using "One in a Million" as more of an expression then a valid statistic. :)
But yeah, your math adds up, though actual field results I'm sure are much lower. 30% of 14 million drives(the number of drives potentially affected) is 4.2 million - we'd be overran with dead drives.
Yeah. I have no idea what's going on with the forum. I don't work directly with AlanM but I imagine he has a set of policies he has to enforce, and that sucks for doing actual dev work on the forums.
The forums are known as dangerous waters for support people to venture in, and forbidden to do so in any official capacity as support agents. But we do read them, especially when things go crazy like this.
You can ask that a CD be mailed to you with the firmware flash on it. We don't publicize it, but we already do that with our normal drive software. So if you absolutely can't go to a friend's house, download and burn the ISO and flash it that way, usually the agent is happy to send you a CD in the mail. If not, ask for a team lead and they'll do it.
The log, if my information is correct, is written each time a SMART check is done. This will always happen on drive init, but can also happen at regularly scheduled events during normal usage, as the drive has to go through various maintenance functions to keep it calibrated and working properly.
The problem with the undetectable bios drives really isn't new. Your customer service knew it for a long time, but they are paid so little and probably have such strict procedures that they don't care about Seagates customers and no one dared to report the drive failures as a major incident. Everyone shut up about it and the people which are responsible and do care only learned about it months later when (or shortly before) it got out to the press.
----
You say that as though it was willful ignorance on the part of the front line support. It really wasn't - most of the time the agents work as far as they can, and if the issue isn't fixable to them, they have to stop and recommend RMA. You will never have a front line agent talk you through hooking up an interface controller serially and issue ATA command instructions to the drive... it's simply out of the scope of support. They rely on people higher up to look at the data and go 'we have a 30% return rate (number pulled out of my ass as an example!) - lets engage QA and find out why!" - until the point that someone from QA or management steps in and goes "We've isolated this issue - here's what it is and here's how to fix it"
Now, a few of them take it on themselves to keep an eye out for issues like this, and actually work on the problem - but most stay within their scope of support and leave it to those who are supposed to be looking out for this kinda thing to do their jobs. Like I said earlier in this thread though, we get too many "problems" that are one-off issues, that it wouldn't surprise me if this was honestly overlooked in a form of group cognitive dissonance as people couldn't comprehend that an issue could have slipped through that would affect so many drives.
I have no idea where the breakdown occurred, but once the issue was isolated, I'm sure there was a managerial OHSHI- and they made them re-prove it... and then someone made a bonehead decision (which is pretty typical and of no surprise to me) to release a public statement without having developed a clear procedure on how to deal with it.