yourbankruptcy,
Actually interesting why not all systems are affected? Only two possibilities: there are two steppings or there is a particular hardware configuration. F.e. all 4P systems are affected, all 2P are not.
I can think of more possibilities for the Itanium 2 bug, I think you will agree. Let's presume that there is a section of logic which is densely packed and has more crosstalk than expected. Further, let's presume that to be affected, a certain pattern of bits needs to flow in parallel through that logic. At a slower clock rate (800MHz) the lines have more time to settle into a voltage which reliably differentiates a one from a zero. Depending on the quality of the silicon at that spot, the etching, and the flowing of metals through the traces, some processors would show the problem at a different speed than others. This would be the explanation of the 'binning' issue - Intel did not know to test for this problem when they binned the processors.
A secondary question arises: Is there a design reason for this section of logic to be packed the way it is (for timing, for instance), or was it a goof? A stepping would fix the latter, but the former problem would be a lot more serious.
This is all very speculative. As Intel isn't saying, we are all guessing. We do know the problem is claimed to be fixed for Madison, which will be 130nm vs. 180nm for Itanium2. Will it be 'fixed' by more careful binning, resulting in less product that runs at the faster speeds, or is there a layout change which will allow Intel to produce processors at their projected clock rates?
I don't know, but I am suspicious because Intel has given so little guidance about the nature of the bug - not even the reproduction scenerio, which they usually tell us. Makes me think the problem is probably more serious than some think.
