Printable View
Yes seems that the barcelona and c2 TLB bug could of caused the same issues. Why it wasn't a big deal on C2 I really don't know maybe no one uses virtual on c2 but again they have not found a TLB bug on nehalem. As jack already mentions this is a spec clarification for something that was found on C2 and already fixed.Quote:
Originally Posted by freeloader
Quote:
Originally Posted by LOE
Wow, you have predicted the future, it's already happening. :D Please tell me should I buy AMD or Intel stock or Mcdonald's? :yepp:Quote:
Originally Posted by JumpingJack
qurious63ss, I don't think you understand the difference between "showstopper bug" and errata... if Intel's CPU are buggy people *will* notice and they *will* have to recall or replace their CPUs the way AMD did.
The odd part is that you don't seem to understand that I -do- understand yet still feel this way.Quote:
Originally Posted by JumpingJack
A showtopper bug is an errata that's sever enough to make a recall because there is now workaround. Anyways, my point was that it even if a chip has 100s of errata it only takes 1 errata for the "show to stop" So you can't just compare chips by the number of errata but the severity of the errata.Quote:
Originally Posted by Jacky
Just to try and keep it simple. I will just paste the short descriptions.Quote:
Originally Posted by freeloader
Quote:
AMD TLB bug:
Under a highly specific and detailed set of conditions, an internal resource livelock may occur between a TLB reload and other cached operations.
Quote:
Intel TLB bug 1:
Under certain conditions when C6 and two logical processors on the same core are enabled on a processor, an instruction fetch occurring after a logical processor exits from C6 may incorrectly use the translation lookaside buffer (TLB) address mapping belonging to the other logical processor in the processor core.
Quote:
Intel TLB bug 2:
Following an exit from core C6, previously logged TLB (Translation Lookaside Buffer) errors in IA32_MCi_STATUS may be cleared.
Implication: Due to this erratum, TLB errors logged in the associated machine check bank prior to core C6 entry may be cleared. Provided machine check exceptions are enabled, the machine check exception handler can log any uncorrectable TLB errors prior to core C6 entry. The TLB marks all detected errors as uncorrectable.
Workaround: As long as machine check exceptions are enabled, the machine check exception handler can log the TLB error prior to core C6 entry. This will ensure the error is logged before it is cleared.
None of the 2 companies actually writes data corruption btw.Quote:
Intel TLB bug 3:
Under certain conditions, writes to IA32_CR_PAT (277H) or IA32_EFER (C0000080H) MSRs may result in an incorrect ITLB (instruction translation lookaside buffer) translation.
First of all you can see that the descriptions are very very different from one another. That itself should show its not something that is related.
Bug 1 for Intel also requires the CPU to be in deep sleep, and have HT on. Both bug 1 and 3 relates to ITLB actually.
Bug 2 you would never see when you run Windows etc. Since machine checks are enabled anyway.
So as with all the other bugs on the AMD and Intel CPUs. Only 1 bug was critical. And that was the AMD TLB bug sofar. All the other 300 phenom bugs and sofar 77 i7 bugs and some 200+ C2 bugs are non critical. But that doesnt make people click on your website...does it? ;)
Just as a fun note from the Phenom list:
For the senstionalist/clueless person. It sounds like something major. Memory instability!!!Quote:
Memory Instability After PWROK Assertion
Or this one:
OMG..it cant calculate correctly!Quote:
A DIV Instruction Followed Closely By Other Divide Instructions May Yield Incorrect Results
It doesnt even know what to execute and when!Quote:
Processor Core May Execute Incorrect Instructions on Concurrent L2 and Northbridge Response
Easy to make something big out of nothing if you want to. And/or doesnt understand what you are reading.
Let's put an end to this. There is no commercial Core i7 having any issue what so ever with TLBs, the performance showed by all the reviewer is correct. The Errata quoted were about Core 2, in April 2007 ...
That is an old stuff that was putted in the Documentation, nothing to worry about.
Hey Francois a bit off topic, but any idea when those Core i7s are heading to the chip loaner program?
I have no clue ... you can get a Gateway machine for 990$ :) with a 920 ...Quote:
Originally Posted by qurious63ss
Sorry I thought you knew what chip loaner program is. It's a program we have in Fab32 11X and I think Oregon has it too where we get a chip for a year to use. Currently I have Q9550 through this program but in January I will be elgible for a new chip. Would love to get a Ci7.
Intel :slapass: FuadQuote:
Originally Posted by Drwho?
Thus far it seems to be vice versa, so far FUD managed to do anything anyway:rolleyes:Quote:
Originally Posted by Ziwro
That's true. Wait till you guys see how many errata GT200 has :up:Quote:
Originally Posted by JumpingJack
I think that the worst was NV40, which made the software driver team completely hate the hardware team :lol:
Personally I don't give a :banana::banana::banana::banana: about erratas or CPU problems from any of the companies. I just want the CPU to work correctly. If that means you have to patch via microcode update or BIOS, so be it.Quote:
Originally Posted by Shintai
BTW...if your system hangs, you'll have a good chance of data corruption. But you know that already. They go hand in hand together. You can argue semantics all you like, but the point is Intel had a bug that could've potentially caused system hangs and data corruption. They fixed it. That's the bottom line.