Sandy Bridge Chipset Shipments Halted Due To Bug
J. Dzhugashvili writes "Early adopters of Intel's new Sandy Bridge processors, beware. Intel has discovered a flaw in the 6-series chipsets that accompany the new processors. The flaw causes Serial ATA performance to 'degrade over time' in 'some cases.' Although Intel claims 'relatively few' customers are affected, it has stopped shipments of these chipsets and started making a revised version of the silicon, which won't be ready until late February. Intel expects to lose $300 million in revenue because of the problem, and it's bracing for repair and replacement costs of $700 million."
They patented slowly degrading performance over time many years ago. It's a key feature built into Windows.
I don't recall seeing any complaints online about degraded SATA performance, so it looks like Intel caught this internally and took the appropriate action before the issue became widespread in the wild. The bug sucks but it just goes to show how difficult it can be to test complex hardware under all situations. Kudos to Intel for being proactive... they have learned from the FDIV bug fiasco, and some other companies with fruity logos might learn from the example.
AntiFA: An abbreviation for Anti First Amendment.
At least I don't have to prove I _need_ high speed SATA performance to get a replacement... clearly SATA is more important than _DIVISION_...
The more I learn about Windows the more I am surprised it runs at all
I RTFA and I for the life of me can't figure out if it's a "The longer the uptime the worse the degrading...and a reboot will start the process over?" or "You will use this and it will get worse and worse untill the chip burns out..."
I hope to god it's the first one...If not this might beat the floating point error by a mile!
Obviously, silicon bugs happen, barely anything makes it out of the fab without an 'errata' list as long as your leg; but the "may gradually degrade over time" part kind of freaks me out.
If it were a "due to a design error, setting register xyz to 0xDEADBEEF causes Serious Badness, chipset drivers are being patched to Never Do That on rev.1 chipsets and future chipsets will be amended" that would be unfortunate; but so it goes. Fully deterministic errors, like the classic division bug, may be problematic; in some cases bad enough to qualify the product as just plain defective; but once known they can be mitigated by not stepping on them. Something that "sometimes" "gradually decreases" performance, on a bus with error correction, though, sounds a lot like a physical problem where some sort of silicon/electrical issue causes error rates to increase and thus retries/corrections to increase in frequency, and user-visible performance to go down. That makes me nervous. It sounds less like a deterministic error problem and more like a certain physical components are actually degrading much faster than expected problem...
Can anybody think of an explanation for how a hardware bug would cause behavior that gradually changes over time(in a manner that couldn't be dealt with with a driver update) that doesn't involve the alarming possibility of gradually increasing error rates and/or early death of onboard SATA ports?
Apparently the problem is with SATA ports 2-5, at least for mobile motherboards. Every desktop board is affected.
Depends on your workload. I'm typing this on a still-just-as-adequate-as-when-I-bought-it A64, plays games and everything; but when I put on my work hat, the fact that we can get more VMs into the same physical volume and power consumption with every generation(and, for annoyingly expensive software that is licensed per-socket, get substantially improved performance for peanuts hardware money) is reason to cheer...
Should have been article title.
Well, I guess this vindicates my decision to stick with MFM hard disks.
Please read my Canon EOS tech blog at http://www.everyothershot.com
The systems with the affected support chips have only been shipping since January 9th and the company believes that relatively few consumers are impacted by this issue.
Important details about shipment date lost in transcription.
Or this one is much more serious... The Pentium FP one was a big issue because of how cagey Intel was about it(and was a genuine problem for users who had purchased it for certain FP heavy operations); but it was a deterministic logical bug: as long as you avoided a fairly specific set of trigger conditions, it would stay safely contained(for certain customers, doing so would likely be so onerous as to qualify as unacceptable; but for everybody else not so scary).
What makes the hair on the back of my neck stand up about this one is the "may gradually degrade" stuff. That makes it sound much less like the "100% of people who do X get bitten/0% of others do" logical bugs and more like the "component degradation in the field can be unpredictable, except at a population level" type of bug that, say, happened to Nvidia not too long back...
I would have thought Intel would consider that to be a feature. Certainly it seems to describe every system I've worked on for the past two decades...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Or, they could be actual quotes from the company's actual press release.
Yeah, it does seem that way, which makes a change. Even though Intel has been here before, it still good to see a company just 'fessing up and dealing with a mistake like this for a change - unlike Dell's blatant denials about their faulty motherboards and Apple's "Antenna Gate".
:)
It's such a shame that they didn't also learn from the much earlier lesson about building on a foundation of rock instead of sand. If only they'd gone with "Rocky Bridge"...
UNIX? They're not even circumcised! Savages!
What's the big appeal of Sandy Bridge anyway ? I still haven't figured out where it fits in the market... mind you, I type this on my dual nehalem, which is still king of the mountain after a year, so I really don't get what the fuss is about. Is Sandy Bridge significantly faster than the original i3/i5 cop-outs ? Or is this a mythical "bang for the buck" platform where everything costs twice as much as AMD ?
I've been building a lot of systems, and Intel dominates the high end, but in my view they haven't sold a decent value processor since the E2xx0 Core 2's. In the desktop market there's really just 3 segments that matter: sub-$500, 500 to 1000, and balls-to-the-wall nutjobs like myself, and AMD has the bottom two tiers in a fierce headlock.
-Billco, Fnarg.com
Yes, if by "line" you mean "unarguably true statement".
Will.I.Am, at his first public Intel press event since being hired, was quoted saying "The problem with the Sandy Bridge Chipset seems to be the dirty bit. BZZZZT BOOM BOOM.... BZZZZT BZZZT BZZZT BOOM BOOOM...." The rest of his comments weren't heard by anyone at the event due to the sudden loud and obnoxious music blaring from all corners...
using System.Awesome;
Comment removed based on user account deletion
I heard Will I Am is so disgusted he's canceling his contract..
My educated guess is that the SATA Input/Output Pads have a digital timing compensation circuit that tries to center the data sampling window (e.g., the clock edge where data is sampled). Since the appropriate data sampling window that won't cause a setup/hold violation changes with process variation and temperature it needs to have lots of potential settings in a large window and may need automatic tracking.
Probably someone didn't design that window large enough to center the data sampling timing offset (or the step size isn't small enough or the auto adjustment circuit that tracks temperature and adjusts the window appropriatly has an algorithmic flaw in some cases, etc). It might be okay now (in early production tests), but as the part ages, the required data sampling window can shift significantly, and if the chip can't adjust the data sampling window appropriatly, then data errors are inevitable.
As a silly example, let's say a hw engineer put in a clock trim circuit that could adjust +-100ps in steps of 10ps. No driver update can make that adjustment -110ps.
Conversely, if the hw control algorithm that tracks temperature and adjusts the window has a postive temperature coefficient over time (say gets slower), but the actual I/O circuit has a negative coefficient over time (say gets faster), after a while, that feedback algorithm may become unstable, that might not be fixable with a driver update either (if the control algorithm is in hw).
Of course, I have no real infomation, but it's my guess having designed high speed I/Os in the past...
32 Intel people will be fired.... unless Hyperthreading is enabled, in which case 64.
Sounds like intel fessed up yesterday and stated it was a problem with a bias circuit in the PLL clocking tree. A bias circuit apparently caused a transistor to remain in a high leakage state (which over time will induce a failure mode). What makes it silly is apparently intel is saying this circuit wasn't in initial designs, added, but not needed in the design and will be disabled in the future... Back to the future!