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."
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.
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...
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...