[FUD] Nehalem also has a TLB bug

[Warboy]

Confirmed by Intel

We were pointed out that Intel's Nehalem, the CPU that we know as Core i7 has TLB. TLB, three letters that have destroyed the sales of Phenom and Opterons based on 65nm K10 cores stands for Translation Lookaside Buffer and Intel officialy states in its Intel Core i7 Processor, Extreme Edition Series and Intel Core i7 Processor - Specification Update PDF that the CPU has a TLB bug.

If you open Intel’s official document that is nicely stored here, on page 37 AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS (TLBS) Invalidation part, you will see that Intel tells that in some rare cases improper TLB invalidation may result in unpredictable system behaviour and can hang your OS or result with incorrect data. Here is the word to word "In rare instances, improper TLB invalidation may result in unpredictable system behavior, such as system hangs or incorrect data. Developers of operating systems should take this documentation into account when designing TLB invalidation algorithms. For the processors affected, Intel has provided a recommended update to system and BIOS vendors to incorporate into their BIOS to resolve this issue."

We are not sure if you should be concerned, but such a thing completely destroyed K10’s reputation and we will certainly do a bit more investigating about it, and ask Intel for a comment. We would like to thank one of our readers for the tip.

Source - Fudzilla


Sidenote - LOL, The first thing that pops up in my address bar when I type FUD is Fudzilla. I wonder why.

[m^2]

Sounds unlikely. I'm waiting for official statement.

[Gramner]

The first thing that pops up in my address bar when I type FUD is Fudzilla. I wonder why.

One would guess that it's because fudzilla.com begins with those three letters.

[Warboy]

One would guess that it's because fudzilla.com begins with those three letters.

....It was a joke....

[Richard Dower]

With this new tech i always new Intel would use folks to beta test.

[Shintai]

Ye for FUDs own....conclusion. He found a TLB text and went nuts.

Standard erratas we got 100s of.

[Richard Dower]

Which is why we have CPU steppings, C0/C1/E0 etc.
Like the P45 chipset...i got an A2 while now they have A3, it sucks but what can you do?

[Warboy]

Which is why we have CPU steppings, C0/C1/E0 etc.
Like the P45 chipset...i got an A2 while now they have A3, it sucks but what can you do?

RMA?

Anyways, based on the article. Intel already patched it.

[Xel'Naga]

Standard erratas we got 100s of.

The only reason AMD went nuts with their TLB errata was because it was a cover-up for their inability to get Phenom at a reasonable frequency.

[Ghostbuster]

Didn't Core 2 had TLB issue as well? http://en.wikipedia.org/wiki/Intel_Core_2

Chip bugs

The Core 2 memory management unit (MMU) in X6800, E6000 and E4000 processors does not operate to previous specifications implemented in previous generations of x86 hardware. This may cause problems, many of them serious security and stability issues, with existing operating system software. Intel's documentation states that their programming manuals will be updated "in the coming months" with information on recommended methods of managing the Translation Lookaside Buffer (TLB) for Core 2 to avoid issues, and admits that, "in rare instances, improper TLB invalidation may result in unpredictable system behavior, such as hangs or incorrect data."[55]

Among the issues noted:

* non-execute bit is shared across the cores.
* Floating point instruction non-coherencies.
* Allowed memory corruptions outside of the range of permitted writing for a process by running common instruction sequences.

Intel errata Ax39, Ax43, Ax65, Ax79, Ax90, Ax99 are said to be particularly serious.[56] 39, 43, 79, which can cause unpredictable behavior or system hang, have been fixed in recent steppings.

Among those who have noted the errata to be particularly serious are OpenBSD's Theo de Raadt[57] and DragonFly BSD's Matthew Dillon.[58] Taking a contrasting view was Linus Torvalds, calling the TLB issue "totally insignificant", adding, "The biggest problem is that Intel should just have documented the TLB behavior better."[59]

Microsoft has issued update KB936357 to address the errata by microcode update, with no performance penalty. BIOS updates are also available to fix the issue.

[informal]

The only reason AMD went nuts with their TLB errata was because it was a cover-up for their inability to get Phenom at a reasonable frequency.

Nope.
TLB erratum affected virtualization drastically and it was the main selling point of Barcelona(or one of the main selling points).The time they dedicated to fix the erratum was planned for speed path optimizations which happened late(B3 got "up to speed" only in Q2/Q3).

As for intel's TLB erratum,it's there alright but it is not a big deal if intel already patched it... I wonder if there is any perf. penalty like Barcelona had with the patch on.

[bowman]

Well, the TLB bug on AMD's was really an errata too, but somehow the tech press went with it until AMD had to add a software fix.. I guess that ain't happening now that it's the blue team. Silly.

Anyway, Nehalem does have the firmware on it so they could fix showstoppers after shipping. Doubt they'll use that for yet another errata that Fuad manages to write yet another non-news news article about..

[Macadamia]

The only reason AMD went nuts with their TLB errata was because it was a cover-up for their inability to get Phenom at a reasonable frequency.

No, the TLB errata supposedly sabotaged their work on the REAL, speedpath-optimized B3 stepping, which should have been a better clocker from the start (yes the TLBfree B3s did that too with CTI, but on a vauger level. It was more of the process and less of the design, I suppose)

So Phenom's only chance to get a better rep was blown because of it.

And no, combining the 2 would mean another 2-3 months, which was unacceptable. AMD refused to do another revision (B4) probably because it wasn't worth it, blotched rep and all.

[Ghostbuster]

As for intel's TLB erratum,it's there alright but it is not a big deal if intel already patched it... I wonder if there is any perf. penalty like Barcelona had with the patch on.

yep it figures, it amd has a TBL bug it is a disaster, but in intel has it - no big deal

Barcelona's TLB errata is different.. http://techreport.com/discussions.x/13724

In order to better understand this problem, TR spoke with Michael Saucier, Desktop Product Marketing Manager at AMD. Saucier confirmed that the TLB erratum can cause the system to hang when the chip is experiencing high utilization. AMD has stated previously that virtualization workloads can lead to this problem, but Saucier clarified that other workloads can trigger system hangs, as well. He characterized the issue as a race condition in the TLB logic "where the other guy wins who isn't supposed to win," and said the likelihood of the erratum causing a system hang is extremely rare.

Saucier flatly denied any relationship between the TLB erratum and chip clock frequencies. He also said there's no relationship between clock speeds and the performance degradation caused by the BIOS-based fix for the erratum. AMD previously cited the TLB erratum as the primary motivation behind its decision to delay the 2.4GHz Phenom variant.

[Chad Boga]

yep it figures, if amd has a TBL bug it is a disaster, but if intel has it - no big deal

it's a funny world we live in

Suggesting that not all TLB bugs are the same.

[informal]

I dunno why you quoted me for. Like Macadamia noted,it practically ate the time that was needed to speed optimize B2 into a B3.B3 became "just" a fixed B2,but lately we can see the progress in speed too,since the TDP drop and improved OCing results confirm the CTI at work.

Anyway,the TLB problem in Nehalem exists,we don't know if there is any penalty from the firmware workaround.

[Xel'Naga]

Nope.
TLB erratum affected virtualization drastically and it was the main selling point of Barcelona(or one of the main selling points).The time they dedicated to fix the erratum was planned for speed path optimizations which happened late(B3 got "up to speed" only in Q2/Q3).

As for intel's TLB erratum,it's there alright but it is not a big deal if intel already patched it... I wonder if there is any perf. penalty like Barcelona had with the patch on.

1. They released the low frequency Phenoms, but not the high frequency ones. The official reason was the TLB eratta, but all frequencies were equally affected.
2. The probability of it appearing was insanely low. I haven't heard of anyone experiencing it, except for AMD engineers under controlled conditions.
Face it...it's just a normal errata. It can cause data corruption or crashes, but it will most likely not appear a single time in the whole lifetime of the CPU. Core 2 Duo, even after 2 year still has over 100 critical bugs.
If anyone is gonna contradict me, please focus on my first point. This is the most important one. If ALL CPUs had the TLB eratta, why did they release the low frequency ones

[informal]

1. They released the low frequency Phenoms, but not the high frequency ones. The official reason was the TLB eratta, but all frequencies were equally affected.
2. The probability of it appearing was insanely low. I haven't heard of anyone experiencing it, except for AMD engineers under controlled conditions.
Face it...it's just a normal errata. It can cause data corruption or crashes, but it will most likely not appear a single time in the whole lifetime of the CPU. Core 2 Duo, even after 2 year still has over 100 critical bugs.
If anyone is gonna contradict me, please focus on my first point. This is the most important one. If ALL CPUs had the TLB eratta, why did they release the low frequency ones

1.It was released at low clocks due to the design and time constraints.They didn't even know about TLB erratum at the launch.CPU clock and TLB erratum have nothing to do with each other.They've found out the bug after the launch and stopped any work on B2 speed optimization-which is reasonable and pure logic.They moved onto a so called "emergency fix" stepping,which B3 fully delivered. B3 got speed "treatment" quite a bit later,in Q2/3 and you can see this clearly in Agena case.
2.The probability of it appearing was insanely low-in desktop usage scenario. The probability in virtualization was quite high and with mission critical apps this is a showstopper. Key words here to focus on: virtualization,showstopper. This is why you saw B2 Phenoms for sale and you can still see them online.This confirms what i've said.Barcelona desperately needed B3 and they focused on it and delivered it.CPU clocks came in later as they lost time to address the erratum in hardware and couldn't use teh same time to do normal speed path optimization.

I addressed the CPU clock in 1. and 2. parts of this post and in my previous posts quite clearly,so i don't know what else to tell you(if you still don't understand it).Macadamia posted similar reply also.

[mikeyakame]

Errata (Sheet 1 of 3)
Number
Steppings
Status ERRATA
C-0
AAJ1 X No Fix MCi_Status Overflow Bit May Be Incorrectly Set on a Single Instance of a DTLB Error
AAJ2 X No Fix Debug Exception Flags DR6.B0-B3 Flags May be Incorrect for Disabled Breakpoints
AAJ3 X No Fix MONITOR or CLFLUSH on the Local XAPIC's Address Space Results in Hang
AAJ4 X No Fix Corruption of CS Segment Register During RSM While Transitioning From Real Mode to Protected Mode
AAJ5 X No Fix The Processor May Report a #TS Instead of a #GP Fault
AAJ6 X No Fix REP MOVS/STOS Executing with Fast Strings Enabled and Crossing Page Boundaries with Inconsistent Memory Types may use an Incorrect Data Size or Lead to Memory-Ordering Violations
AAJ7 X No Fix Code Segment Limit/Canonical Faults on RSM May be Serviced before Higher Priority Interrupts/Exceptions and May Push the Wrong Address Onto the Stack
AAJ8 X No Fix Performance Monitor SSE Retired Instructions May Return Incorrect Values
AAJ9 X No Fix Premature Execution of a Load Operation Prior to Exception Handler Invocation
AAJ10 X No Fix MOV To/From Debug Registers Causes Debug Exception
AAJ11 X No Fix Incorrect Address Computed For Last Byte of FXSAVE/FXRSTOR Image Leads to Partial Memory Update
AAJ12 X No Fix Values for LBR/BTS/BTM will be Incorrect after an Exit from SMM
AAJ13 X No Fix Single Step Interrupts with Floating Point Exception Pending May Be Mishandled
AAJ14 X No Fix Fault on ENTER Instruction May Result in Unexpected Values on Stack Frame
AAJ15 X No Fix IRET under Certain Conditions May Cause an Unexpected Alignment Check Exception
AAJ16 X No Fix General Protection Fault (#GP) for Instructions Greater than 15 Bytes May be Preempted
AAJ17 X No Fix General Protection (#GP) Fault May Not Be Signaled on Data Segment Limit Violation above 4-G Limit
AAJ18 X No Fix LBR, BTS, BTM May Report a Wrong Address when an Exception/Interrupt Occurs in 64-bit Mode
AAJ19 X No Fix Performance Monitoring Events for Read Miss to Level 3 Cache Fill Occupancy Counter may be Incorrect
AAJ20 X No Fix A VM Exit on MWAIT May Incorrectly Report the Monitoring Hardware as Armed
AAJ21 X No Fix Use of Memory Aliasing With Inconsistent Memory Type May Cause Unpredictable System Behavior
AAJ22 X No Fix Delivery Status of the LINT0 Register of the Local Vector Table May be Lost
AAJ23 X No Fix Performance Monitor Event SEGMENT_REG_LOADS Counts Inaccurately
AAJ24 X No Fix #GP on Segment Selector Descriptor that Straddles Canonical Boundary May Not Provide Correct Exception Error Code
AAJ25 X No Fix Improper Parity Error Signaled in the IQ Following Reset When a Code Breakpoint is Set on a #GP Instruction
AAJ26 X No Fix An Enabled Debug Breakpoint or Single Step Trap May Be Taken after MOV SS/ POP SS Instruction if it is Followed by an Instruction That Signals a Floating Point Exception
AAJ27 X No Fix IA32_MPERF Counter Stops Counting During On-Demand TM1
AAJ28 X No Fix Intel® QuickPath Memory Controller tTHROT_OPREF Timings May be Violated During Self Refresh Entry
AAJ29 X No Fix Processor May Over Count Correctable Cache MESI State Errors
AAJ30 X No Fix Synchronous Reset of IA32_APERF/IA32_MPERF Counters on Overflow Does Not Work
AAJ31 X No FIx Disabling Thermal Monitor While Processor is Hot, Then Re-enabling, May Result in Stuck Core Operating Ratio
AAJ32 X Plan Fix The PECI Throttling Counter May Not be Accurate
AAJ33 X No Fix PECI Does Not Support PCI Configuration Reads/Writes to Misaligned Addresses
AAJ34 X No Fix OVER Bit for IA32_MCi_STATUS Register May Get Set on Specific lnternal Error
AAJ35 X No Fix Writing the Local Vector Table (LVT) when an Interrupt is Pending May Cause an Unexpected Interrupt
AAJ36 X Plan Fix A Processor Core May Not Wake Up from S1 State
AAJ37 X Plan Fix Reading Reserved APIC Registers May Not Signal an APIC Error
AAJ38 X Plan Fix A Logical Processor Receiving a SIPI After a VM Entry Into WFS State May Become Unresponsive
AAJ39 X No Fix Memory Controller May Deliver Incorrect Data When Memory Ranks Are In Power-Down
AAJ40 X No Fix Faulting MMX Instruction May Incorrectly Update x87 FPU Tag Word
AAJ41 X Plan Fix A Floating-Point Store Instruction May Cause an Unexpected x87 FPU Floating-Point Error (#MF)
AAJ42 X Plan Fix Incorrect TLB Translation May Occur After Exit From C6
AAJ43 X Plan Fix USB 1.1 ISOCH Audio Glitches with Intel® QuickPath Interconnect Locks and Deep C-States
AAJ44 X Plan Fix Stack Pointer May Become Incorrect In Loops With Unbalanced Push and Pop Operations
AAJ45 X No Fix A P-state Change While Another Core is in C6 May Prevent Further C-state and Pstate Transitions
AAJ46 X Plan Fix Certain Store Parity Errors May Not Log Correct Address in IA32_MCi_ADDR
AAJ47 X No Fix xAPIC Timer May Decrement Too Quickly Following an Automatic Reload While in Periodic Mode
AAJ48 X No Fix Certain Undefined Opcodes Crossing a Segment Limit May Result in #UD Instead of #GP Exception
AAJ49 X No Fix Indication of A20M Support is Inverted
AAJ50 X No Fix Reported Memory Type May Not Be Used to Access the VMCS and Referenced Data Structures
AAJ51 X Plan Fix After VM Entry, Instructions May Incorrectly Operate as if CS.D=0
AAJ52 X Plan Fix Spurious Machine Check Error May Occur When Logical Processor is Woken Up
AAJ53 X No Fix B0-B3 Bits in DR6 For Non-Enabled Breakpoints May be Incorrectly Set
AAJ54 X No Fix Core C6 May Clear Previously Logged TLB Errors
AAJ55 X Plan Fix Processor May Hang When Two Logical Processors Are in Specific Low Power States
AAJ56 X Plan Fix MOVNTDQA From WC Memory May Pass Earlier Locked Instructions
AAJ57 X No Fix Performance Monitor Event MISALIGN_MEM_REF May Over Count
AAJ58 X No Fix Changing the Memory Type for an In-Use Page Translation May Lead to Memory-Ordering Violations
AAJ59 X Plan Fix Writes to IA32_CR_PAT or IA32_EFER MSR May Cause an Incorrect ITLB Translation
AAJ60 X Plan Fix The "Virtualize APIC Accesses" VM-Execution Control May be Ignored
AAJ61 X Plan Fix C6 Transitions May Cause Spurious Updates to the xAPIC Error Status Register
AAJ62 X Plan Fix Critical ISOCH Traffic May Cause Unpredictable System Behavior When Write Major Mode Enabled
AAJ63 X Plan Fix Running with Write Major Mode Disabled May Lead to a System Hang
AAJ64 X No Fix Memory Controller Address Parity Error Injection Does Not Work Correctly
AAJ65 X No Fix Memory Controller Opportunistic Refreshes Might be Missed
AAJ66 X Plan Fix Delivery of Certain Events Immediately Following a VM Exit May Push a Corrupted RIP Onto The Stack
AAJ67 X Plan Fix The Combination of a Bus Lock and a Data Access That is Split Across Page Boundaries May Lead to Processor Livelock
AAJ68 X Plan Fix CPUID Instruction Returns Incorrect Brand String
AAJ69 X Plan Fix An Unexpected Page Fault or EPT Violation May Occur Following the Unmapping and Re-mapping of a Page
AAJ70 X No Fix Infinite Stream of Interrupts May Occur if an ExtINT Delivery Mode Interrupt is Received while All Cores in C6
AAJ71 X No Fix Two xAPIC Timer Event Interrupts May Unexpectedly Occur
AAJ72 X No Fix EOI Transaction May Not be Sent if Software Enters Core C6 During an Interrupt Service Routine
AAJ73 X No Fix FREEZE_WHILE_SMM Does Not Prevent Event From Pending PEBS During SMM
AAJ74 X No Fix PEBS Records For Load Latency Monitoring May Contain an Incorrect Linear Address
AAJ75 X No Fix PEBS Field “Data Linear Address” is Not Sign Extended to 64 Bits
AAJ76 X Plan Fix Core C6 May Not Operate Correctly in the Presence of Bus Locks
AAJ77 X No Fix Intel® Turbo Boost Technology May be Limited Immediately After Package C-state Exit with QPI L1 Mode Disabled

this is from current spec update for c0 retail stepping. i see at least 3 possible tlb related bugs, but none critical enough to be a problem much like i see many other bugs expected from a new m-arch and which will be corrected or worked around with newer silicon steppings over the next 6-12months.

[Rammsteiner]

Also I think AMD's TLB bug came in a very unfortunate time.

They had to get back on track after Conroe was pretty much making K8 sweat and they were hoping at K10. But after TLB bug patch performance dropped even more. They had to spend their time to fix this instead of making further improvements. Deneb got quite delayed AFAIK due to the B2 stepping.

Whether Intel will get hurt by this... Dont know, if they're already patched there's no issue really. Also Intel is in the position now to have a few flaws as well, AMD really didnt have that back then.

[003]

So for i7 owners, is this something we need to worry about?

[informal]

So for i7 owners, is this something we need to worry about?

Nope.

[Movieman]

My 965 has been at 100% load 24/7 since Nov3.. No issues seen yet..
Let's hope this isn't a huge issue.

[nn_step]

Didn't Core 2 had TLB issue as well? http://en.wikipedia.org/wiki/Intel_Core_2

Yes, but mostly because x86 underspecified the TLB implementation [all of them did; Intel, Cyrix, AMD, VIA, and many others] and because of that little stupid mistake, the market used the current implementation [aka the shipping silicon] as the full specification. Thus those who were significantly conservative of there use of the TLB, have had very few to no problems in their software but those who liberally applied tricks relating to the TLB basically got screwed.
[Fortunately AMD didn't make such as mistake with the x86_64 specification]

[Jacky]

IIRC the same sensationalist crap was posted by FUD or Inq back then about "core2's tlb bug". I'm confident that sandy bridge and westmere will too have some kind of errata relating to the TLB and I'm sure FUD is going to post the same crap all over again. Just because it's such a catchy headline.