I took a visit over to Slashdot today and noticed this thread about the firmware circus (click, here, here, and here to catch up if you’ve missed anything). While reading it, I noticed this comment from someone named “Maxtorman” who identified themselves as a Seagate employee (Seagate owns Maxtor just in case you didn’t get the joke behind his name). The comment (assuming it’s true, which I have little doubt that it is) gives an interesting insight to the decision making that went on internally when it came to this firmware. Here’s the important bits that you need to know:
This whole thing started with the 1.5 Terabyte drives. It had a stuttering issue, which at first we all thought was a simple bad implementation of SATA on common chipsets. Seagate engineers promptly jumped in and worked to try to duplicate the issue and prove where the problem was. This wasn’t a massive rush as 1.5tb drives are what? 5% of the drives on the market. When it became obvious that the issue was more widespread, they buckled down and put out a couple of firmware revisions to fix it.
Now, in the 1.5tb drives, there are 2 main revisions. the the product line that gets the CC* firmware, and the line that gets the SD* firmware. They came out with firmware CC1H and SD1A to fix these issues and started issuing them.
But, seagate has always been restrictive of handing out their firmware, so such updates required calling in with your serial so that the people who had access to hand out the firmware could check a) model, b) part number, and c) current firmware just to make absolutely sure that they were giving the right firmware out. This has been a procedre that has worked for YEARS up until now.
Then the bricking issue came to their attention. It took so long because it’s an issue that’s hard to track down – pretty much the journal or log space in the firmware is written to if certain events occur. IF the drive is powered down when there are 320 entries in this journal or log, then when it is powered back up, the drive errors out on init and won’t boot properly – to the point that it won’t even report it’s information to the BIOS.
This is a rare, but still obviously bad issue. Up until now, we all figured it was just some standard type of failure, as it was such a rare event, so we’d RMA the drives.
So, for whatever reason, mid management started freaking out (as it could be a liability for seagate, I suspect – ontop of the already potentially liable issue of the stuttering problem causing drives to fail in RAIDs). So, they pushed the release of the SD1A firmware to the general public. They took a few days to ‘test’, though it was mostly just including some code in the batch file that kicks off the firmware updater, to check that it is a BRINKS drive, and the proper model number. Then it was kicked out to the public.
Please understand, this firmware had to go through five different checks to make sure it applies to the specific conditions to qualify sending to a customer, before now. 5 chances for us to go your drive needs the other (or none) firmware update. Suddenly, it’s down to ONE check, and even that was more designed for a contingency just incase the wrong firmware was sent out.
Of course, it starts bricking drives.
Okay, so it’s the old story of somebody in a position of power making a decision to push something out the door to make a problem go away, bypassing a bunch of checks and balances in the process. I suspect that all the people complaining about these drives and the story propagating across the Interwebs was the problem they had to solve.
But there is some potentially good news:
The good news is, the chance of your drive simply not spinning up one day is very low. And for those of you who flashed the wrong firmware – be patient. It’s not bricked, just unable to write data to the platters properly. When they have a *GOOD* firmware out, a new flash should un-brick the drives. If not, flashing it back to SD15 should make it work again.
IF that’s true, then Seagate has a way out. We of course won’t find out until new (hopefully properly validated) firmware ships. Still that’s cold comfort to people who have “bricked” drives.
I still see a class action lawsuit headed right for Seagate.
Like this:
Like Loading...
Related
This entry was posted on January 21, 2009 at 1:31 pm and is filed under Commentary. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Seagate Employee Gives The Facts About The Firmware Mess On Slashdot
I took a visit over to Slashdot today and noticed this thread about the firmware circus (click, here, here, and here to catch up if you’ve missed anything). While reading it, I noticed this comment from someone named “Maxtorman” who identified themselves as a Seagate employee (Seagate owns Maxtor just in case you didn’t get the joke behind his name). The comment (assuming it’s true, which I have little doubt that it is) gives an interesting insight to the decision making that went on internally when it came to this firmware. Here’s the important bits that you need to know:
This whole thing started with the 1.5 Terabyte drives. It had a stuttering issue, which at first we all thought was a simple bad implementation of SATA on common chipsets. Seagate engineers promptly jumped in and worked to try to duplicate the issue and prove where the problem was. This wasn’t a massive rush as 1.5tb drives are what? 5% of the drives on the market. When it became obvious that the issue was more widespread, they buckled down and put out a couple of firmware revisions to fix it.
Now, in the 1.5tb drives, there are 2 main revisions. the the product line that gets the CC* firmware, and the line that gets the SD* firmware. They came out with firmware CC1H and SD1A to fix these issues and started issuing them.
But, seagate has always been restrictive of handing out their firmware, so such updates required calling in with your serial so that the people who had access to hand out the firmware could check a) model, b) part number, and c) current firmware just to make absolutely sure that they were giving the right firmware out. This has been a procedre that has worked for YEARS up until now.
Then the bricking issue came to their attention. It took so long because it’s an issue that’s hard to track down – pretty much the journal or log space in the firmware is written to if certain events occur. IF the drive is powered down when there are 320 entries in this journal or log, then when it is powered back up, the drive errors out on init and won’t boot properly – to the point that it won’t even report it’s information to the BIOS.
This is a rare, but still obviously bad issue. Up until now, we all figured it was just some standard type of failure, as it was such a rare event, so we’d RMA the drives.
So, for whatever reason, mid management started freaking out (as it could be a liability for seagate, I suspect – ontop of the already potentially liable issue of the stuttering problem causing drives to fail in RAIDs). So, they pushed the release of the SD1A firmware to the general public. They took a few days to ‘test’, though it was mostly just including some code in the batch file that kicks off the firmware updater, to check that it is a BRINKS drive, and the proper model number. Then it was kicked out to the public.
Please understand, this firmware had to go through five different checks to make sure it applies to the specific conditions to qualify sending to a customer, before now. 5 chances for us to go your drive needs the other (or none) firmware update. Suddenly, it’s down to ONE check, and even that was more designed for a contingency just incase the wrong firmware was sent out.
Of course, it starts bricking drives.
Okay, so it’s the old story of somebody in a position of power making a decision to push something out the door to make a problem go away, bypassing a bunch of checks and balances in the process. I suspect that all the people complaining about these drives and the story propagating across the Interwebs was the problem they had to solve.
But there is some potentially good news:
The good news is, the chance of your drive simply not spinning up one day is very low. And for those of you who flashed the wrong firmware – be patient. It’s not bricked, just unable to write data to the platters properly. When they have a *GOOD* firmware out, a new flash should un-brick the drives. If not, flashing it back to SD15 should make it work again.
IF that’s true, then Seagate has a way out. We of course won’t find out until new (hopefully properly validated) firmware ships. Still that’s cold comfort to people who have “bricked” drives.
I still see a class action lawsuit headed right for Seagate.
Share this:
Like this:
Related
This entry was posted on January 21, 2009 at 1:31 pm and is filed under Commentary. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.