Slashdot Mirror
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.
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.
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
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...
Or, they could be actual quotes from the company's actual press release.
Sandy Bridge is the successor to Nehalem. It uses less power and is more efficient.
The current P67 boards (LGA 1155) are for the mainstream market, e.g. Best Buy, Futureshop, Fry's, Staples, etc. They're basically "high-end' for the middle-class.
Wait until LGA 2011 comes out (successor to 1366). You'll be thinking of switching then. :)
Yes. Sandy Bridge i7-2600K CPUs are approaching the speeds of the i7-980X, while costing 1/3rd as much. You can build an insanely fast machine for under $1000 with Sandy Bridge, including graphics card.
My blog. Good stuff (when I remember to update it). Read it.
What's the big appeal of Sandy Bridge anyway ?
For some of us (including me), the big deal is that Sandy Bridge adds a new set of instructions called "AVX" intstructions, which let us do more floating-point operations at the same time. For some scientific apps this can nearly double the performance of the overall app.
There are a number of really good articles on the advances in Sandy Bridge. For instance:
http://www.realworldtech.com/page.cfm?ArticleID=RWT091810191937
http://www.anandtech.com/show/3922/intels-sandy-bridge-architecture-exposed
To summarize some of the things I remember off the top of my head:
The design is basically area-equivalent to the Nehalem designs, but they've made certain structures more space efficient to make room to enlarge others. For instance, they've made the branch predictor use fewer bits for the same prediction accuracy. This and other improvements have allowed them to increase critical structures that affect things like the instruction window size. The instruction window pertains to the number of decoded but not executed instructions out-standing. A larger instruction window allows you to (a) find more instruction-level parallelism because you're more likely to find independent instructions that can be executed simultaneously, and (b) absorb the effect of some high latency operations, like L2 cache misses -- you can effectively hide much of the latency by continuing to look for and perform unrelated work during the stall. In Nehalem and before, they had a structure that unified the reservation station, register file, and reorder buffer. Logically, this makes sense, but it also makes that area very power hungry, and you can never turn it off. In Sandy Bridge, they've split those structures, so they can be clock-gated separately. Also, instead of accumulating dependency results in the reservation station, they're stored in a single centralized physical register file, and pointers are held in the RS. This saves a lot of space, since now instructions traveling around the processor just need to carry the pointer. (This does add some latency and writing required to fetch those results from the RF when they're finally needed.)
It's explicitly stated that Sandy Bridge is not a major revolution in processor design. Compared to Nehalem, you might think of it representing a large collection of efficiency improvements that work together to make a processor that is faster (clock for clock efficiency) and more power efficient.
Many of these improvements lead to the larger instruction window. IMHO, this is a critical improvement. A Sun engineer once described modern processing as being a race between last-level cache misses. You have an L2 miss, and you quickly run out of work to do, and the processor stalls until that out-standing read arrives. Meanwhile, you've accumulated a hundred cycles or so of pending work, which gets blasted through, and execution continues perhaps a little while until you have another L2 miss. Processors like Nehalem can execute four or more instructions per cycle (peak), but the effective AVERAGE instructions per clock is less than 1. These high-latency L2 misses are primarily responsible for that. Besides adding on-die memory controllers, which reduces the latency, Sandy Bridge lengthens the instruction window so as to absorb more of that latency, so that stall time is less.
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...