TLB bug... did it ever affect anybody?

Quote:

---

Originally Posted by saaya

thanks jumping jack for clarifying! :toast:

so this was overblown big time by amd and the press...
after all i dont even understand why amd made the tlb fix mandatory, that was really stupid... you basically slow down everybodies systems cause 0.01% has a problem... ts...

---

Frankly, almost every errata this publicized is overblown be it Intel or AMD that is affected. Even the FDIV bug in the pentium so many years ago was given more importance than needed. The problem is the psychological affects that people take away of 'this is a defective CPU', many times forgetting that both AMD and Intel document dozens to hundreds of odd bugs that rarely if ever occur.

AMD did the right thing by stopping any Barcelona/Opteron going into enterprise systems given the nature of the bug and the importance data centers put on up-time and stability, on DT (most of what people here are interested in), the TLB errata may or may not express itself, if it does the frequency is most probably not high enough to ever notice as lock ups, BSOD, etc. all simply occur on occasion be it from a CPU errata, a bad driver, or poor microsoft OS code... we all deal with the occasional lockup etc. If the errata were occuring every 2 hours, it is a problem, if it occurs every 2 months... would anyone notice (most definitely not).

The rigors that both Intel and AMD put the CPU through before launch should bolster confidence that under normal operations the processor will function just fine.... that is not that they should not fix errata as they become known, most certainly the most problematic ones need to be fixed -- and they are usually in future steppings, however, most errata are so minior or not typically observed with commercial software that though it is documented, both AMD and Intel simply to not plan to fix it ... there is really no need.

The severity of the TLB errata is much more in the bad PR it has generated than any problematic build one might assemble. I personally will wait for B3 before considering a Phenom build, part of it is the TLB, I prefer to have it not there -- but they will also fix other bugs as well, which for a first rev I would rather wait.

Jack

AMD has to come out and mentioned the errata mainly due to OEMs and large corporation orders, since they will sue them for more if they hadn't and are the main bodies who maybe affected, as in they or their customers stand the most chance to replicate the small window of time needed to observe this bug. TLB needing to set an A or D bit > only way the bug can occur.

My uncles corp. has over 200 Phenom builds running in his department since early November, mine was one of them too. It's a govenment funded medical institution across the nation and running full load medical work, some desktop systems are running 24/7 with research similar to folding but more optimized and they have no TLB bugs appear. The problems they did have are motherboard and support related.

The TLB bug has not and will probably never transpire on desktops with desktop usage. I can gurantee that reviewers would've tried their best to get it to appear but they also couldn't just like anyone else so far. I only tried running VMWare which I always do for Gentoo, Fedora Core, Ubuntu, Slackware and it worked fine at 2.42GHz and below.

Like I said somewhere earlier, some journalists are jumping on the "hot news" bandwagon too early before something is understood and risking their reputation for valid communication by blowing things far too out of proportion as well as spreading misinformation. As far as I can see, Scott at TechReport seems to be the one that started this "mass worry" by writing this piece of inaccurate news on the 6th December: http://techreport.com/articles.x/13741

Quote:

---

AMD admitted the presence of the erratum prior to the Phenom's public introduction, but the firm's initial statements gave the impression that the erratum affected only virtualization, which is a server-class application and an uncommon use for a desktop CPU. In truth, the erratum can cause instability with desktop-style usage patterns, as well, and systems with Phenom 9500 and 9600 processors will have to be patched and suffer the accompanying performance penalty.

---

This is very far from reality. In fact, let me quote another long time reviewer, Kyle of [H], who I don't normally quote when it comes to graphics, but he has played with more Phenoms than many reviewers have and what he says here is absoultely factual. 20th December: http://www.hardforum.com/showpost.ph...5&postcount=54

Quote:

---

I would like to know why anyone would think the TLB issue does impact desktop consumers? Maybe some websites have not really represented this correctly to enthusiasts because they have other agendas? First I would like to know where you read that about PS because I would like to look into that more. Sort of hard to prove a negative, so where are the websites proving it is an issue that have harped on it?

The problem cropped up in some very specialized virtualization applications under full load. To my knowledge no one has ever seen this issue manifest on the desktop. That said, we moved away from Adobe application testing as they are simply a pain in the ass to use because of licensing hoops that have to be jumped through.

---

So, people need to stop worrying. If you have seen the bug manifest, then please do report it here. I doubt you ever will because that would be caught very easily by microprocessor testing by the manufacturer, and this cannot be.

Hmm after runnning linpack over night it looks like this atm:

http://www.abload.de/thumb/bildschirmfoto3u7.png

As you can see not all calulations passed.
I use the Asus M2A-VM board and they released a new bios version 1604 on 12/21/07. I compared the everest cache/mem results and this version must have the tlb fix included.
So i upped my bios and started linpack again. Will post results tomorrow.

thx justapost!
i never actually used linpack so no idea what this screenshot means

i think the bug most likely only apears when using virtualization...
and thats probabaly why amd is reducing the amount of cpus they sell as opterons and are fixing the bug asap. otherwise they robabaly wouldnt pay so much attention on fixing it.

but kte, i think it was also the fault of amd and not just the press that this got overblown so much. keep in mind amd pr used this tlb bug as an excuse for no 2.6ghz desktop parts being available at launch... which was ust that, an excuse, and a really bad one as it raised everybodies attention in this bug and made everybody panic...

Quote:

---

Originally Posted by saaya

thx justapost!
i never actually used linpack so no idea what this screenshot means

---

Hmm linpack also fails with the tlb fix applied, so i have a library or an other hardware stability issue here.
The bug should freeze or power down the system i think, so this linpack failures have nothing todo with it.
http://www.abload.de/thumb/bildschirmfoto-149d.png

Quote:

---

Originally Posted by saaya

i think the bug most likely only apears when using virtualization...
and thats probabaly why amd is reducing the amount of cpus they sell as opterons and are fixing the bug asap. otherwise they robabaly wouldnt pay so much attention on fixing it.

---

I wish they would give an reproducable example of a workload triggering the bug.

Good work justapost. :toast:

The bug will lockup the system if it occurs.

Saaya, I think they had problems with speed scaling long before this bug was noticed. namely in January 07.

KTE
So it's overrated
Thanks very much

Quote:

---

Originally Posted by KTE

metro.cl: why would you want the bug to appear?

Let alone 2+ hours, I've done over 144 hours continuous without it at 2.42GHz CPU 1.98GHz NB/HT an Cooper must have done high hours too. If it doesn't appear for you, it just won't with desktop loads since P95 and FPU Julia is the heaviest desktop load I've seen yet possible.

---

Too see if it happens, what happens and how often.

I read Jmping Jack explanation thanks for it.

Quote:

---

Originally Posted by Lightman

Now I know that Intel has TLB error as well :D (j/k)

---

half year ago:
http://www.theinquirer.net/en/inquir...re-cpus-is-out
http://www.theinquirer.net/en/inquir...e-2-cpu-errata

http://support.microsoft.com/?kbid=936357

:clap:

the problem i see here was not the actual errata, but the performance drop which is resulted by applies errata fix. no journalist mentioned in his review that you don't need the fix since all the tasks are working perfectly fine w/o it and system is fully stable...otherwise how could they got the results w/o the fix.

Quote:

---

In truth, the erratum can cause instability with desktop-style usage patterns, as well, and systems with Phenom 9500 and 9600 processors will have to be patched and suffer the accompanying performance penalty.

---

this is pure incompetence BS. Even with virtualization it'll take quite unusual scenario to get the TLB errata

Quote:

---

Originally Posted by saaya

so its possible to NOT use the fix then? nice!
nobody replied so far... so i take it nobody had any stability issues without the tlb fix?

---

Never had issues with the bug. Only issue I have is they ship some severely crappy bios with these new 790FX boards so far. One hopes customers will be able to quit beta testing bios for them soon.

so still nobody who managed to trigger the tlb bug?

Very good explanation of Errata 298 is here!

Must read whole page before that conclusion to get it right:)

Quote:

---

... What does all of this have to do with Erratum 298 or the bug it describes? The answer is very simple: Only in situations where hardware virtualization is used and there is heavy load on the CPU can there be a race condition where the wrong TLB data may be written to the L3 cache before being updated in the L2 cache. Since the TLBs are used to find the task-specific data within the virtual memory address space, this could lead to updating data in system memory with data that do not pertain to the task at hand but to another cached operation. This is generally referred to as data corruption. Does any of this affect the standard Desktop user? Sure, when hell freezes over. Especially in any situation where Microsoft Vista is used, the entire thing is a completely moot point since the OS will crash a gazillion times before the “Erratum 298” bug is encountered. ...

---

BTW great review! :clap:

Quote:

---

Originally Posted by Lightman

Very good explanation of Errata 298 is here!

Must read whole page before that conclusion to get it right:)


BTW great review! :clap:

---

Only read the conclusion so far. I wonder what hardware virtualisation functionality must be used.
Xen 3.0.1 makes use of hardware virtualisation but does not use the new features coming with k10. I could not trigger an error with win2k3 guests running prime95.
Does somebody know what level of hardware virtualisation microsofts hyper V (comin with the 2008rc1 server) uses?

Over all bad news for me as i plan to run virual machines on my phenom. So once xen does full hardware virtualisation i must run with the tlb-fix.

Quote:

---

Originally Posted by justapost

Only read the conclusion so far. I wonder what hardware virtualisation functionality must be used.
Xen 3.0.1 makes use of hardware virtualisation but does not use the new features coming with k10. I could not trigger an error with win2k3 guests running prime95.
Does somebody know what level of hardware virtualisation microsofts hyper V (comin with the 2008rc1 server) uses?

Over all bad news for me as i plan to run virual machines on my phenom. So once xen does full hardware virtualisation i must run with the tlb-fix.

---

I think by that time we will get microcode update for Phenom and performance hit will be lower...
Today I will be testing new beta F4 BIOS for GA MA790FX-DQ6 which contains new code from AMD. Hopefully that is microcode upgrade ;)

Speaking of which when is AMD gonna update the source code any word?

what source code?