Erratum Plagues Quad-Core Opterons, Phenoms

theraindog writes "Errata are not uncommon with new processors, but a problem with the TLB logic in AMD's quad-core Opteron and Phenom processors appears to be quite serious. The erratum is so severe that AMD has issued a 'stop ship' order on all quad-core Opterons. AMD has also blamed this bug for the delay of the 2.4GHz Phenom, despite the fact that the erratum is unrelated to clock speed. A BIOS-based workaround for the issue has been made available to motherboard makers, but it apparently carries a 10-20% performance penalty. What's more disturbing is that AMD knew of the erratum and the potential performance hit associated with fixing it before it launched the Phenom processor. Hardware provided to the press for reviews did not include the fix, conveniently overstating Phenom performance."

Comments

NDA for patch?

[Cajun Hell]

Check this out:

Linux users may have another option in the form of a patch for that operating system's kernel. Sources estimate this patch's performance hit at less than one percent, but it comes with several caveats. At present, the patch purportedly only applies to the 64-bit version Red Hat Enterprise Linux, Upgrade 4. Customers must sign a non-disclosure agreement in order to obtain the patch...

Good thing it's just a patch, as opposed to a derived work of someone else's GPLed code. I wonder what the FSF guys would say about that. I also wonder: Red Hat, why?

Old issue, really

[Uzito]

My good old Opteron 170 had the same stupid issue with unsynched core clocks. What is new here?

Re:Old issue, really

[zsouthboy]

"The "true" quad-core line appears to be nothing more than marketing hyperbole"

No, it's not marketing.

You're not seeing the usefullness on the desktop.

HPC is another story - and it's also the place that the plain old Opteron has been holding its own, against the faster, clock per clock, Core 2 microarchitecture.

Having requests go through the FSB (which is a WTF this day and age) kills cache snooping, etc, between cores.

The "true" quad core doesn't have this problem.

Re:"because", not "despite"

[Wavicle]

You have to read a follow-up article to the techreport.com one here: http://techreport.com/discussions.x/13724. Which reads:

Apparently contradicting prior AMD statements on the matter, Saucier flatly denied any relationship between the TLB erratum and chip clock frequencies. He also said there's no relationship between clock speeds and the performance degradation caused by the BIOS-based fix for the erratum.

I imagine that is where the article got the information.

Let's not forget..

[AcidPenguin9873]

that Intel's Core 2 also had a problem with the TLB when first released, although that problem manifested itself as data corruption instead of a lockup. Here are the two articles from The Inquirer about it - the second one especially. And note that this document was released after Intel had shipped the buggy Core 2's.

However, Intel was able to fix it without incurring a large performance loss. It's a shame for AMD that they weren't able to do the same.

Perfect Linux CPUs

[evilviper]

Ironically, these may turn into the CPUs dejour for Linux users...

The performance hit is probably 10% when patching the microcode which should mean steep price mark-downs on this generation of CPUs. But it's only a 1% performance hit when patching the (Linux) kernel.

So why doesn't every OEM that sells Linux servers and desktops just buy up all of AMD's supplies of defective chips at a big discount, and pass the savings along? I'd buy a couple.