Printable View
Hey guys,
i just wondered... did anybody actually experience problems before flashing to a bios that contained the microcode update to fix the tlb bug? i havent really heard from anybody... and seeing as this tlb fix reduces perf quite a lot in some situations... wouldnt it make sense to not use it?
would be nice if we could disable the fix in bios right?
or is this possible already?
The New DFI 790 Bios has it on by default but you can turn it off that is a option.....to bad the 12/11/07 Bios is Pure trash and probably does more harm then good :rolleyes:
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?
Have never had it yet at stock or up to 2.9GHz during gaming, WCG, P95 or any other bench. Every problem has mainly been AOD/BIOS/MB. But because the platform components have so many problems of their own yet people may start to attribute other errors as "the bug". It's a common thing in ignorance, I pondered it too. :D
If you experience it, you will experience it at stock too and only under very heavy loads.
+1Quote:
Originally Posted by KTE
Tried two Phenoms on several boards
Not experienced up to 2.5GHz...
At 2.6GHz though under Vista x32 I had blue screen with message saying something along the lines: Windows has not received interrupt from a second core in expected time...
That :rolleyes: of course might be a typical Vista error if you're running unstable OC
I haven't played with Vista too much so I'm not sure :p:
BTW new Gigabyte BIOS has Errata298 DISABLED by default and you can ENABLE it if you wish (is there anyone willing to do that?? :stick: )
Could you explain this detailed?Quote:
Originally Posted by Brother Esau
The wisdom of the thread ... truth of the matter, systems lock up for various reasons, trying to attribute to this specific bug would be difficult at best... as the other platform bugs get squashed, the rate of occurrence of any lockup would most likely not be anything noticable or outside the norm...Quote:
Originally Posted by KTE
Most people would simply curse M$ anyway.... heck, the last round of 'Vista updates' wreaked havoc on one system, I had to go back with system restore 5 days just to get back to where I am day on day stable again.
sounds like one of your cores cant run 2.6ghz, check if you can find out which one, maybe the other cores can hit 2.8+ and you only have to keep one down at 2.5 :DQuote:
Originally Posted by Lightman
well im starting to think this bug either only affects a small percentage of cpus, or it only happens in situations that none of us are ever going to get to. i mean if we dont run into any issues even when ocing then this bug cant be as bad as amd made it sound like.
wtg for hyping up this errata and scaring all your customers amd! :stick:
I heard it was only under certain circumstances when all four cores are fully loaded with virtualization software...?
aka: it shouldn't happen to the vast majority
The explanation of Errata 298Quote:
Originally Posted by Zertz
Virtualization exhaserbates the issue since the resource sharing will change context depending on loading of the cores. However, the actual errata can trigger just by running multithreaded code in which the page is labeled in correctly. This is part of a cache coherency problem and not restricted soley to virtualization.Quote:
The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h
What this basically is saying is that there are a few cycles between the time a page table is altered and the time the table is marked dirty. If a core grabs that shared memory (say a multithreaded program is using the same page table) before it is marked, then it will incorrectly load the wrong data into L3.
EDIT: But a strong point needs to be made.... that window of time is likely very small, so small that the probability of happening is slim to none ... this errata does not give cycles of time that it takes to update the TLB and even if it is 10's of cycles, it is such a small window, for typical DT usage one may never actually trigger it and if it does, the frequency of M$ blunders would overwhelm the signal. :)
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...
I havent used it and been using my Phenom 9500 @ 2.6 for about 3 weeks now with no problem, I dont intend to ever patch it cause I know it wont ever be an issue lol.
Run mine at 2.6Ghz 24/7, no errors here.
Thank you JumpingJack for another clarifying post.
This TLB issue was so overblown!
Did you ever look at ATI's and NVIDIA's "Readme"| files about driver issues with all drivers they're launching!
When you start reading what is still unsolved, and what can crash your system, you would never buy graphics card!
Competition used this "confession" of AMD and did some spinning with "friendly" media eventually creating the disastrous picture. Now, when dust is finally little settled, we can see how overblown this thing was.
I experienced that blue screen during 2008rc0 installation on xen. Win2k3 worked flawless.Quote:
Originally Posted by Lightman
http://www.abload.de/thumb/bluescreen32x.jpg
Quote:
Originally Posted by justapost
That's the one :p:
Thanks! Now I know that Intel has TLB error as well :D (j/k)
Achim
Do you have HPET timer enabled in the BIOS?
The only bug i have right now is this Dang Cold bug... Cough Cough, Sneeze Sneeze.. Dang Weather outside.
Maybe someone can tell how to make the bug appear, we have 2 configurations here, and have don over 2+ hours of continuous stress, with rendering, gaming, etc... and still no sign of it.
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.
how about linpack? did anybody try that yet?
No, it was recommended to disable HPET to run linux.Quote:
Originally Posted by KTE
@saaya: had probs building linpack, might try later again.
Edit: Got it, runs without problems with a problem size of 20000 under denian/lenny (64bit).
Well the error did not occure on a c2d laptop i had here for testing.Quote:
Originally Posted by Lightman
It occured only on the phenom system.
HPET Timer enabled is the cause of BSODs and instability for some people on Phenom/790FX. Just FYI. :)
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.Quote:
Originally Posted by saaya
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
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=54Quote:
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.
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.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.
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...
Hmm linpack also fails with the tlb fix applied, so i have a library or an other hardware stability issue here.Quote:
Originally Posted by saaya
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
I wish they would give an reproducable example of a workload triggering the bug.Quote:
Originally Posted by saaya
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
Too see if it happens, what happens and how often.Quote:
Originally Posted by KTE
I read Jmping Jack explanation thanks for it.
half year ago:Quote:
Originally Posted by Lightman
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.
this is pure incompetence BS. Even with virtualization it'll take quite unusual scenario to get the TLB errataQuote:
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.
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.Quote:
Originally Posted by saaya
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:)
BTW great review! :clap: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. ...
Only read the conclusion so far. I wonder what hardware virtualisation functionality must be used.Quote:
Originally Posted by Lightman
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...Quote:
Originally Posted by justapost
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?