backtop


Print 64 comment(s) - last by clnee55.. on Dec 24 at 2:33 AM

Much of AMD's bad luck over the last three months revolves around a nasty bug it just can't shake

Erratum, to those in the hardware or software industry, is a nice way of saying "we missed a test case" during development and design. 

Yesterday, The Tech Report confirmed AMD's iteration of Intel's F00F bug.  The bug, which has been documented since at least early November, can cause a deadlock during recursive or nested cache writes. 

How does the TLB erratum occur?  All AMD quad-core processors utilize a shared L3 cache.  In instances where the software uses nested memory pages, this processor will experience a race condition. 

AMD's desktop product marketing manager Michael Saucier describes a race condition as a series of events "where the other guy wins who isn't supposed to win." 

In the software world, a typical memory race condition occurs when the memory arbiter is instructed to overwrite an older block of memory, but write the old block of memory to somewhere else in cache.  In the instance where two arbiters follow this same rule set, its easy to see how a race condition can occur: both arbiters attempt to overwrite the same blocks of information, resulting in a deadlock.

From what AMD engineers would tell DailyTech, this example is very similar to what occurs with nested memory pages in virtualized machines on these K10 processors. 

AMD has since released a new BIOS patch for all K10 motherboards, including the often cited but rarely seen MSI K9A2 Platinum.  This patch, confirmed by DailyTech, will result in at least a 10% reduction in general computing speed. 

AMD partners tell DailyTech that all bulk Barcelona shipments have been halted pending application screening based on the customer.  Cray, for example, was allowed its latest allocation for machines that will not use these nested virtualization techniques.  Other AMD corporate customers were told to use Revision F3 (K8) processors in the meantime. 

The TLB erratum will be fixed in the B3 stepping of all AMD quad-core processors, including Phenom and Barcelona.  However, AMD considers the B3 stepping a "March" item on its 2008 roadmap.  Processors shipped between then and now will still carry the TLB bug, though with the BIOS workaround these machines will not experience a lockup. 

The delayed Phenom 9700 is affected by the TLB bug, though AMD insiders tell DailyTech the upcoming 2.6 GHz Phenom 9900 is not affected.  This indicates Phenom 9900 will carry the B3-stepping designation.

AMD's latest roadmap hints that its tri-core processors are merely quad-core processors with one core disabled. The company also indicated that it will introduce some of these tri-core processors with the L3 cache disabled.  Removing the shared-L3 cache from the chip design eliminates the TLB bug.

In a likely-related event, AMD's newest corporate roadmap scheduled three Phenom processors for the first half of 2008; one of which is the Phenom 9700.  The company will launch eleven new 65nm K8 processors in the same time period.


Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: Not good
By TomZ on 12/5/2007 1:12:15 PM , Rating: 2
From what I understand, it would be bad for consumers, since probably most motherboards will have the microcode workaround applied in the BIOS, which has the nasty side effect of a 10-20% performance hit.

Also, from what I understand, the bug doesn't just occur when running virtualization software. It just happens to be that running virtualization software is the most likely trigger.


RE: Not good
By KristopherKubicki (blog) on 12/5/2007 1:15:29 PM , Rating: 2
From my understanding there has to be a nested memory page and high utilization. There are lot of occasions when this can happen, but I think the only way you could really duplicate persistant nested memory pages is with virtualization.


RE: Not good
By 16nm on 12/5/2007 2:41:53 PM , Rating: 3
The silver lining in all of this is, assuming that the AMD board and management are not a bunch of monkeys and buffoons, that they will learn from this mistake and make sure it never happens again. I am reminded of the Pentium 586 math bug that caught a lot of headlines in the nineties. Intel learned a lot from that mistake. Mistakes reveal our weaknesses and how to fix them.

Intel made a mistake in Netburst, now look how they're improved.

However, you must see the irony in a quad core server CPU failing at virtualization. One of the most compeling reasons for business to buy quadcore machines is for server consolidation through virtualization. LOL. That sucks big time!


RE: Not good
By KristopherKubicki (blog) on 12/5/2007 3:50:50 PM , Rating: 2
That does seem like a pretty big oversight..


RE: Not good
By Master Kenobi (blog) on 12/5/2007 6:20:15 PM , Rating: 2
Yea, on the desktop or workstation end, quad core is nice but not critical. Quad core servers on the other hand offer virtualization on multiple servers without the heavy licensing and hardware costs normally associated with it.


RE: Not good
By erikejw on 12/6/2007 4:54:33 AM , Rating: 2
Well, was the released Phenoms with the BIOS that made them work 100% albeit somewhat slower or were they with a faulty BIOS that is faster.

If it was fully working they will do better against the Core2 processors but probably a little slower anyway.


RE: Not good
By qwertyz on 12/6/2007 10:44:25 AM , Rating: 1
the BIOS fix will most probably disable the 2 MB L3 cache


RE: Not good
By clnee55 on 12/24/2007 2:33:08 AM , Rating: 2
quote:
That does seem like a pretty big oversigh


The validation engineer who missed the floating point bug at Intel was probably got fired. I wonder if he works in AMD now.


RE: Not good
By kalak on 12/7/2007 1:30:02 PM , Rating: 2
quote:
Mistakes reveal our weaknesses and how to fix them.


I agree, but AMD/ATI public image is becoming very bad... that's a shame.... Please react AMD !


RE: Not good
By Andypro on 12/5/2007 2:54:46 PM , Rating: 2
Kris: I noticed that you use the word "utilize" excessively in your articles. That's a waste of bytes. Utilize doesn't have any added meaning beyond "use." Try to utilize the better word from now on :p


RE: Not good
By TomZ on 12/5/07, Rating: 0
RE: Not good
By KristopherKubicki (blog) on 12/5/2007 3:42:25 PM , Rating: 2
Nah its a bad habit. When you write about the same thing over and over again it gets easy to use the same words repeatedly. "slate" is another word I'm trying not to use.


RE: Not good
By Egger on 12/5/2007 8:34:21 PM , Rating: 2
Not to be a grammar police or anything, but in all honesty there is a slight difference between 'use' and 'utilize', as 'utilize' infers the meaning of 'to make use of', as in 'to use despite being of other uses as well [as the referred use]'. So in most cases, the word 'utilize' that Kristopher uses is correct.

Sorry to be a troll and post once every ten years despite lurking constantly, just trying to provide occasional positive input really.


RE: Not good
By qwertyz on 12/5/07, Rating: -1
RE: Not good
By Oregonian2 on 12/5/2007 2:18:27 PM , Rating: 2
ROTFL


RE: Not good
By Oregonian2 on 12/5/2007 3:10:38 PM , Rating: 3
Somebody appears to not have liked my laughing at the obvious tongue-in-cheek joke that someone posted (*ALL* processors ever produced in the history of semiconductors have had bugs in every version produced -- even the comparatively trivial 8080/Z80 processors had bugs in nice eratta sheets (I design embedded processor systems and have since the 8008 processor (as the HW circuit designer))).


RE: Not good
By Myrandex on 12/5/2007 2:41:37 PM , Rating: 2
[sarcasm] Hell Yeah! Especially since no other CPU manufacturer ever has bugs in their designs! Also Software should be held to these standards, so no more Software can be sold again since none is bug free! [/sarcasm]


RE: Not good
By Clauzii on 12/5/2007 5:46:42 PM , Rating: 2
Talking about flicking the big red switch :o


"I f***ing cannot play Halo 2 multiplayer. I cannot do it." -- Bungie Technical Lead Chris Butcher

Related Articles













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki