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.

A bad block is a bad block - it's marked corrupted and that block's LBA address is reassigned to a replacement block on the end of the track. Once a block is reallocated, it's as though the old block doesn't exist according to the firmware. The driver won't help you at all - the old block no longer even has an LBA address. I guess it still have a physical address that may be accessed if you know what you're doing, but that'sa bit over my head at this point.

Very possibly! It could have forced a new write of the log and bypassed the bug. Other people are reporting that the drive comes up again if power cycled a few times... so i think you may have gotten lucky in that respect.

Yeahh.. about that.
Chat is *not* where we keep our brightest agents.

I'll leave it at that.

As far as I know, no drives with 3.AAJ are affected. Keep an eye on the KB article though - if your model shows up there, then call in and see whats going on, no matter your firmware. Sadly, this is kinda the downside of the corporate push to be the first to have the fastest, highest capacity drives on the market. :( Drives die, dude. Some drives last a decade, others are dead out of the box. Backup, Backup, Backup. If your data's important to you, you should have at least 2 copies or more on different media. Internal harddrive, backed up to an external harddrive once a week is good enough for most people. Not foolproof, but good enough. I'd say this weather I worked for Seagate, IBM, Hitachi, or WD. Back your important data up - all drives fail eventually.

1 word: Lawsuits. if they gave incorrect information, it could open them up for liability if people acted o that information. When a business' data could be worth millions, one slip-up could cost them dearly. The only reason this firmware isn't such an issue, because of the disclaimers allover the place when you flash a drive.

yes, the 1.5Tb drives both stutter and are at risk of bricking due to the journal issue. The Stuttering issue is fairly recent and mostly runs in the 1.5tb drives - but the journal issue is older and exists across many 7200.11 drives. ES2 drives and Diamondmax drives.

SD1A fixes both of these problems in the 1.5Tb drives.