The problem in the chipset was traced back to a transistor in the 3Gbps PLL clocking tree. The aforementioned transistor has a very thin gate oxide, which allows you to turn it on with a very low voltage. Unfortunately in this case Intel biased the transistor with too high of a voltage, resulting in higher than expected leakage current. Depending on the physical characteristics of the transistor the leakage current here can increase over time which can ultimately result in this failure on the 3Gbps ports. The fact that the 3Gbps and 6Gbps circuits have their own independent clocking trees is what ensures that this problem is limited to only ports 2 - 5 off the controller.
You can coax the problem out earlier by testing the PCH at increased voltage and temperature levels. By increasing one or both of these values you can simulate load over time and that’s how the problem was initially discovered. Intel believes that any current issues users have with SATA performance/compatibility/reliability are likely unrelated to the hardware bug.
One fix for this type of a problem would be to scale down the voltage applied across the problematic transistor. In this case there’s a much simpler option. The source of the problem is actually not even a key part of the 6-series chipset design, it’s remnant of an earlier design that’s no longer needed. In our Sandy Bridge review
I pointed out the fair amount of design reuse that was done in creating the 6-series chipset. The solution Intel has devised is to simply remove voltage to the transistor. The chip is functionally no different, but by permanently disabling the transistor the problem will never arise.
To make matters worse, the problem was inserted at the B-stepping of the 6-series chipsets. Earlier steppings (such as what we previewed last summer) didn’t have the problem. Unfortunately for Intel, only B-stepping chipsets shipped to customers. Since the fix involves cutting off voltage to a transistor it will be fixed with a new spin of metal and you’ll get a new associated stepping (presumably C-stepping?).
While Steve wouldn’t go into greater detail he kept mentioning that this bug was completely an oversight. It sounds to me like an engineer did something without thinking and this was the result. This is a bit different from my initial take on the problem. Intel originally characterized the issue as purely statistical, but the source sounds a lot more like a design problem rather than completely random chance.