AMD Phenom X4 9750 Quad Core CPU Review

Fatal Flaw or Bad PR? Finally Fixed with B3

As anyone who has worked in the computer industry knows, CPUs and their micro-architecture are always flawed. Most of these so called flaws or “errata” are so obscure that most never effect anyone in the real world; sure you can setup a scenario in a controlled environment that will highlight it but for the most part they are benign. Heck, most are the equivalent of saying: “stand on one foot, stick you other foot straight out, spin around in place while patting your head and tummy at the same time, all the while singing the Oh Canada!....backwards in Esperanto and while doing all this your ability to factor PI to 10,000 places may be negatively impacted.” Yeah, they usually are that vague and most every CPU has them. Take a look at the errata list for the Intel C2D and you will be astonished at the sheer number of these little nit-picks. Intel/AMD/etc are aware of them and simply fix them in future revisions and distribute BIOS level work arounds (or mirco code updates) to the motherboard manufacturers, and life goes on.

Unfortunately, not all errors are small, complex nor as benign as the example above; some errors are so mind-bogglingly huge and significant that the CPU maker issues a RECALL on all of them. The largest example of this was with the original Pentiums and their inability to do floating point math properly (in extremely rare and weird scenarios). Back then having a built in FPU (aka “math coprocessor”) was a big deal and yet Intel borked it so badly that ALL of those amazing (for the time) powerhouse chips were recalled. Yes an error in a mere 1 in 9 billion floating point divides was enough to recall them ALL.

Recently, AMD had a “major” error in their shiny new native quads with the B2 silicon that was probably much more unlikely to have any real world negative effect. This error was the translation lookaside buffer error or “TLB error” for short. To understand what a translation lookaside buffer error means, you first have to understand what the TLB does. This is going to be a cliff notes version of it, so please forgive us if we over simplify a very complex issue.

As I am sure you all know, most (if not all modern) Operating systems use “virtual memory” in which program A thinks it is accessing blocks A through D and program B thinks it is also has using these blocks, when in fact neither are necessarily using these memory address blocks. Virtualization of the memory allows multiple programs to all run happily together without the need for complex or messy memory managers to be built into said programs (rather its done at an OS level). What the OS does is store a table of all these mappings in memory and to make things even more quick the CPU can also store a copy of this table in its internal cache.


Now, since the lookup table is in cache its faster than accessing an external memory manager but searching this table (which can get LONG) and then using said table takes valuable clock cycles that could be used for other things, so what the CPU engineers decided was to make a buffer of the cache which has a list of the actual one to one mappings already done. The TLB is none other than this table of translations of virtual to physical mappings and since the mappings are already done the CPU doesn’t need to go do a cache lookup making it even faster again!

As we use the OS, programs are going to be swapped in and out of memory and thus the cache and TLB have to updated on a regular basis. This sounds simple but cache table entries have to be handled very carefully otherwise you could end up in a situation where two CPUs have different data….which is a bad thing and can result in a hard lockup of the computer, or even worse still silent data corruption! This is where the notorious TLB errata comes into play. Under certain circumstances the logic that handles how the complex dance of marking and moving and updating of the page table can go awry. In a nut shell, you could end up in a bad situation where two CPUs have conflicting lookup data in there L2 cache. At best this can result in a hard lock BUT the more sinister problem is silent data corruption. From an enthusiasts point of view things are made even worse as this error becomes more and more likely the faster the cores run. This is why AMD set the upper cutoff at 2.4GHz, for their first Phenom CPU release schedule.

The funny thing is that Intel found a similar bug in its C2D line last year but because they can do micro code updates on their chips (bug fixes in the CPUs logic. Think of it as being able to update the BIOS of the chip itself….’ish) they were able to handle it. Unfortunately, AMD does not have this ability and as such got skewered by the Intel marketing machine.


Because AMD was unable to do a machine code update they had to resort to a BIOS level kludge. This so called “fix” for all intents and purposes turned OFF the TLB’s ability to look in the cache. Needless to say this was the sledgehammer / nuclear bomb approach to fixing the error. Heck, some programs suffered some down right HUGE performance hits to the point where a cheaper and slower DUAL X2 would outperform it but even when you take the average of a 10% performance hit, that is one honkin’ big hit.

For the B3 line (aka new and improved version) which we are reviewing here today, it is a hardware fix which is still more of a workaround than a real fix as it does incur a performance hit. It is no longer a huge hit and is in fact very minor, but it is still a hit. The upside is the TLB can now access the cache properly and thus be a lot more efficient.


Well that is the past and this is now. AMD has fixed this error and hopefully, in time, will be able to recover from this devastating blow. Things do look grim but AMD is a fighter which has overcome longer odds in the past. So lets now take a close look at what AMD has brought to the table!