I was closing some windows on my laptop and came across an unsaved document in an unselected tab in my text editor that had some interesting info in it: the notes from my phone call with AMD, just prior to the Phenom launch, when I first learned about the TLB erratum. Looking at those notes, I learned something that came as a bit of a shock: I had flubbed a fact in our coverage of the TLB erratum story.
I wrote more than once in our coverage of the erratum that AMD had initially suggested the problem didn’t affect lower clock speeds of the Phenom. Turns out that’s not the case. Here is the text of my notes, verbatim:
TLB problem w/virtualization
2.4 will have the complete fix
Have to enable something in the BIOS for the 2.2 and 2.3
Can degrade perf a little bit
I knew, after receiving this news, that something had caused me to bracket out this problem as a minor detail rather than a major problem, and I later attributed that to the erratum being confined to higher clock frequencies. I even said mistakenly in my Phenom review that the TLB erratum only happened at higher frequencies. I think I may have read this incorrect information online somewhere, but that is no excuse. I had better info myself and didn’t keep it straight.
In truth, the reason I originally bracketed out the TLB erratum as a minor issue was because AMD said it only affected virtualization and that a BIOS-based switch would offer an optional workaround. Since virtualization is much more commonly used in servers than in desktop processors, the TLB erratum seemed like a minor inconvenience affecting a small handful of users, not a big problem.
Of course, as we’ve reported, the TLB erratum can cause system hangs in a broader range of contexts, including desktop workloads, and probably for this reason, AMD has directed its partners not to include a switch in the system BIOS to disable the workaround. The erratum and its workaround will affect virtually all Phenom owners every day, as a result.
I’m proud that we were first to break the news of AMD limiting Opteron shipments due to the erratum, first to provide more detail about the nature of the workaround, and first to quantify its considerable performance impact. I believe this was very important follow-up work after our review of the product, and I stand by my conclusions in the last article, in particular.
But I’m deeply sorry that we flubbed a key fact in our coverage of this story. I should have re-checked my notes before writing the Phenom review, let alone the other stories on this issue. Most importantly, perhaps, I should not have made incorrect assertions that could potentially damage AMD’s reputation during an already difficult period. I would also like to apologize personally to the individual at AMD who initially provided us with the TLB erratum information.
The information AMD first gave us about the problem did indeed mis-portray the TLB erratum as a minor issue for the Phenom, but not for the reasons we reported. As for whether AMD was trying to hide something when it first informed us about the TLB issue, I am now officially agnostic. I’ve not looked into "who knew what when?" timelines in my coverage of this story, and it’s entirely possible AMD did not yet realize the TLB erratum extended beyond virtualization to broader desktop usage patterns prior to the Phenom’s public introduction. I really don’t know about that.
I will be making minor corrections in our three TLB erratum stories to reflect the fact that AMD did not initially say the TLB erratum was limited to higher clock frequencies. Beyond this one issue, I still believe the substance of our TLB erratum coverage is essentially correct—and is very important information for potential owners of Phenom 9500 and 9600 processors.