According to an Intel spokeswoman, the problem has to do with the actual circuitry inside the McKinley processors, not with operating system or application software that runs on them. While the spokeswoman would not say what percentage of Itanium 2 processors might be affected by the glitch, what she did say is that only a percentage of the Itanium 2 processors made to date have a glitch, and a slightly smaller percentage of them would experience instability or a crash because of the electrical circuit problem because specific instructions in the Itanium core and specific kinds of data have to be manipulated by a faulty chip for problems to become apparent.
Intel has developed a test to check for the problem, which OEMs making McKinley-based machines and customers already using them in the field can use. This test will be available through Intel’s support organization and through OEMs. Having identified a potentially bad chip, customers have two options. First, they can clock down the Itanium 2 processor to 800MHz. The problem does not manifest itself on chips that are slowed down from 900MHz or 1 GHz to this speed. Or, they can contact their OEM or Intel to get a replacement Itanium 2 processor, free of charge, that has been screened and identified as glitch-free.
Intel does not, said the spokeswoman, plan to suspend shipments of McKinley processors. She also says the company is using the same test to ensure that the chips it ships now don’t have the problem.
Jim Dunlap, a spokesperson for Itanium partner Hewlett Packard Co, which helped create the Itanium family of chips, says HP has not stopped shipping its McKinley-based products and has worked with Intel to implement a methodology to identify potentially troublesome chips and prevent them from crashing customer machines. IBM Corp, which just two weeks ago announced the xSeries 450, its first Itanium 2-based server, has not, according to company sources, in any way decommitted to Itanium, but the company is working with Intel to absolutely ensure that the test for the bug works perfectly before it resumes shipments of the xSeries 450, which it halted last Friday.
According to Intel’s spokeswoman, earlier this year, an OEM partner (which she would not name, and which neither IBM nor HP would admit to being) reported some issues with the McKinley processor as part of its own stress testing on the processors. After months of trying to figure out if it was a hardware or software problem, Intel concluded it is a problem in the chips themselves. The 900MHz /1.5MB L3 cache, 1GHz/1.5MB L3 cache, and 1GHz/3MB L3 cache versions of the McKinley are all affected by the glitch. Grimes says the problem is not found in the forthcoming 1.5GHz/6MB L3 cache Madison Itanium 2 processor that Intel is set to debut in mid-2003. This latter processor has been giving RISC/Unix servers a run for the money is recent weeks on popular benchmark tests. That the McKinley chips have a glitch is a problem, but if the Madison chips did, it would be a real headache for Intel and its OEM partners.
This is not the first problem Intel has had with its Itanium processors since they launched, by the way. In the summer of 2001, Compaq, now part of HP, identified a bug in the 733MHz and 800MHz Merced Itanium processors, the original Itanium chips, during some intense stress testing. HP and Intel said at the time that they had not found any customers who had experienced any problems like those it saw in the labs, but just to be on the safe side, the two vendors provided free Itaniums to customers who identified theirs as being susceptible to the bug.
Source: Computerwire
