I'do not not think they add a feature on there cpu, intel since the dawn of time has always sell patched cpu they just found a more economical way of patchin their stuff AMD want to give the better quality produc like they say good stuff sell by himself.
And I would not be happy anyway to buy a cpu 300$+ that need once in a while a patch to work, And every one take that feature it is a great thing, Dam it it don't work take it back and give me somting that work.

To me this is just a big fat lie. The real reason is probably due to low yields.

Can you pls post the link to the errata - would love to read it myself

While I do not dismiss that this is an issue, it's not clear to me that this is the cause for the launch delays and lower bins at launch.

Is this issue specific to desktop (Phenom) only? If it is a general issue to K10, why are there no 2.0-2.4GHz K10's available right now? Theoretically they should be able to pump out 2.2GHz and 2.3GHz parts out on Barcy with no problems, no?

Call me a skeptic but this seems like a convenient excuse and I think there are issue(s) beyond this TLB errata limiting the clockspeeds of the Phenom at release.

It also seems quite late in the game to be finding this out, as I believe even this trusted rag mentioned that there were Phenom samples (internal) that were clocking much higher (May 7,2007):

"We understand that people in Austin were 'dancing in the aisles'. When asked if that was because of B0, we were told that people are very happy, very very happy, but he had 'never heard of such a thing'."

"So what do you end up with? A massive gain in frequency. How massive? Almost 500MHz. Instead of the much touted launch parts, look for five SKUs at launch, AM2 quads at 2.6GHz, 2.7GHz and 2.9GHz, a dual at 2.7GHz and a quad on socket F at 2.8GHz."

In the words of Bob Eucker... juuuusssst a little outside...and I suppose now we are to believe the massive shift in bins is due to this TLB errata?

Either AMD knew about this problem much earlier then they have let on and they are now using it as an excuse to cover up other issues, or their validation process leaves a lot to be desired.

If the decode of an instruction includes a vector that doesn't work, you substitute a new vector. This isn't rocket science and Intel wasn't the first to enable fixes.


This couldn't be a problem with an unvectored decode, because that would have turned up months ago.

If this really is a speed-bin problem, why can some 2,3 GHz parts overclock to 3,0GHz without any problems? Why cant AMD just launch some of theese as a 2,4GHz part?

the author does not know anything, truly dumb nutshell inside.

AMD has sucessufully succumbed to automationitis. Each successive chip design beyond k7 gets added delays. All due to a 'don't rock the boat' policy. 
Translation Layoff Beaurocracy.
Anyone daring to stick their head above the mountain of position stuffers is quickly silenced.

TLB is "translation lookaside buffer", not "transition...".

Looking at the way things are going, it should be amd.ati.com, not the other way around.

I mean, 7-series chipset emerged thanks to ATI, HD3800 is also their child. All while AMD is struggling to produce a 65nm part above 2.4 (er, 2.3)Ghz frequency. I used to REALLY like AMD. Used to...

Triumph of business over engineering. I bet they can all point to perfect paperwork. 

AMD is an engineering company not a business. The business part needs only to support the engineering company not nine to five it.

re: "or will the Texas part of the company still consist out of 9 to 5vers who will go home at 5PM and not fix problems that are causing this company to bleed"

If they wanted to they could employ a night shift team for this sort of thing. In fact why not the whole hog and employ round the clock development and testing? 

Do this for 2 years, it will increase costs but should buy them some tech advantage. It won't be cheap, but it's an option.

Honest question:
Do you know what you are talking about ? 

For using a Microcode update, you have to integrate it into the BIOS, so it could be loaded during system start up.

Now you praise Intel for having a MicroCode patch (obviously, loaded via a bios update) and then you criticize AMD for working on a BIOS update (obviously for a Microcode patch).

Please do a proper read up, before you are stating such nonsense ...

cheers

Alex

P.S: 
you might start to read here:
http://www.securiteam.com/securityreviews/5FP0M1PDFO.html 


Is it just me or is it difficult to understand why 2.4Ghz has a big problem and needs to wait for a new revision and 2.3Ghz is just OK?

I just found a video on YouTube and do not know if anyone else is aware of it:

http://www.youtube.com/watch?v=i_q_9a4zDps

An AMD tech demonstrates the Phenom 2.2Ghz CPU and at the end of the vid he takes it to 3.0Ghz. I don't know if this was a handpicked part, but it does show the lowest graded quad Phenom being able to reach 3.0Ghz if not for any specified amount of time.

You obviously haven't noticed, but AMD have had the ability to do microcode updates since the K7. As it turned out, they broke the microcode update functionality in the later K7's, but fixed it again for the K8's.

The thing about microcode updates is that they only allow fixing a small subset of features. Just like Intel can't fix all the Core 2 bugs with microcode updates, AMD can't fix all the K8/Barcelona bugs with microcode updates. The only difference is that one of AMD's bugs is a showstopper ...

"This problem was found during speed-binning the B2 revision processors, and this was the cause for the Phenom FX 3.0 GHz delay." seems to imply that before they found this errata, they had no idea what was causing the problem with 3.0ghz parts. 

So does that mean there is a chance higher clocked parts will be released sooner? I mean, if it's just a bios update to fix the problem, what's the hold up?

Infact, if just updating the bios fixes the issue, why did they need to pull the 2.4ghz part from stores? Did I miss something?

http://www.securiteam.com/securityreviews/5FP0M1PDFO.html

This sounds like a case of a driver transister for a block of memory/registers being too weak (hard to be more specific several thousand miles away from their test lab though)... AMD would not be alone in being caught by this particular class of gotcha. ;)

The good thing is that AMD have spotted this problem *before* they started shipping the faster parts... Anyone remember Intel's FDIV bug ?

If my guess is right AMD should not find this one too hard to fix. In the meantime there is a chance that you might be the lucky owner of a part that was blessed by the Process Gods.