[FUD] Nehalem also has a TLB bug

Quote:

---

Originally Posted by FUDzilla

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.

Sounds unlikely. I'm waiting for official statement.

Quote:

---

Originally Posted by Warboy

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.

Quote:

---

Originally Posted by Gramner

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

---

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

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

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

Standard erratas we got 100s of.

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?

Quote:

---

Originally Posted by 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?

---

RMA? :p:

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

Quote:

---

Originally Posted by Shintai

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.

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

Quote:

---

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.

---

Quote:

---

Originally Posted by Xel'Naga

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.

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..

Quote:

---

Originally Posted by Xel'Naga

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.

Quote:

---

Originally Posted by informal

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.

---

Quote:

---

Originally Posted by LOE

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

---

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

Quote:

---

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.

---

Quote:

---

Originally Posted by LOE

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

it's a funny world we live in

---

Suggesting that not all TLB bugs are the same.

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.

Quote:

---

Originally Posted by informal

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:shrug:

Quote:

---

Originally Posted by Xel'Naga

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:shrug:

---

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.

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.

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.

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

Quote:

---

Originally Posted by 003

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

---

Nope.

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

Quote:

---

Originally Posted by Ghostbuster

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]

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.

This story is a complete crap!
The TLB bug in AMD is different from Intel's Clarification on how to handle TLB Invalidation.
Moreover what FUD says doesn't affect just Nehalem but nearly all previous generations as well

Quote:

---

Originally Posted by 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.

---

QFT! I guess this news sent "AMD dancing in the isles" LOL!:rofl::ROTF:

Quote:

---

Originally Posted by Donnie27

QFT! I guess this news sent "AMD dancing in the isles" LOL!:rofl::ROTF:

---

"isles" or "aisles"? :D

Anyway, which reminds me http://www.theinquirer.net/en/inquir...l-ceo-confirms Charlie in the bunny suit is much funnier... :rofl:

Quote:

---

Originally Posted by Mr Ottelini

"It's a good thing you write better than you gamble otherwise you'll be living in that outfit."

---

:ROTF:

How does FUD assume that this is a bug? In the linked document it is labeled as "clarification", not errata.

Quote:

---

Originally Posted by m^2

Sounds unlikely. I'm waiting for official statement.

---

Why?
The list of known bugs for every individual Intel (and AMD) CPU type is pages long.

The whole hype around AMDs TLB bug was just another demonstration on how the common IT consumer web community lacks respectable wisdom.

Indeed, AFAIK this TLB bug is already in documentation from Intel right at their own site. And if it ain't a big issue, then I dont think they'll make some sort of huge announcement about it.

Although, depends on how FUD & Co blow it up:rolleyes:

F:shakes::shakes:K.

No, it won't be a problem for i7 prospectors. And no, I don't think this means AMD fans will be dancing in the aisles. More likely, it will just be met with head shakers as the response to this will likely be muted in comparison. Both TLB bugs involve data corruption and both can be fixed in the same BIOS patch manner. Both can be experienced in rare circumstances. Both are unlikely to ever be encountered by normal end-users. Response: "But Intel's is different! It isn't a big deal but AMD's was the end of the f'king universe!"

Bleh. They're both over-hyped issues that we aren't going to experience.

When do you guys think the X58 motherboard vendors will get around to addressing this issue?

seems fuad needs some money for his christmas presents. :rofl:

Hmm I wonder if this is why so many review sites have gone out of their way to avoid any virtualization tests on Shanghai, which is where it stands head and shoulders above the competition's current and next gen hardware. There'd be no comparison to the current gen Xeon, and if this affects Nehalem performance, Intel wouldn't have a leg to stand on.

Granted, there's alot of if, and's, and but's in there and a bit of a conspiracy theory, but still! :D

Quote:

---

Originally Posted by AuDioFreaK39

When do you guys think the X58 motherboard vendors will get around to addressing this issue?

---

It can also be fixed in the operating system because this only happens when it does an improper TLB invalidation. ;)

EDIT: Refer to the first page of this thread...

Quote:

---

Originally Posted by Particle

No, it won't be a problem for i7 prospectors. And no, I don't think this means AMD fans will be dancing in the aisles. More likely, it will just be met with head shakers as the response to this will likely be muted in comparison. Both TLB bugs involve data corruption and both can be fixed in the same BIOS patch manner. Both can be experienced in rare circumstances. Both are unlikely to ever be encountered by normal end-users. Response: "But Intel's is different! It isn't a big deal but AMD's was the end of the f'king universe!"

Bleh. They're both over-hyped issues that we aren't going to experience.

---

Tier 1 Server OEM's weren't prepared to risk it with Barcelona, no doubt based on their own testing.

If they are with Nehalem, that will say whether the TLB bugs are of similar severity, not posters on a forum, that's for sure.

what goes around comes around?

swings and roundabouts?

lol it just makes me laugh :ROTF:

but hey to fair to Intel, i think errata is the new buzz word now a days, as has been said before, there are hundreds.

So this bug is fixed with an bios update. Soemhone here compared a fixed with an unfixed bios? I don't think so.

Quote:

---

Originally Posted by Ghostbuster

It can also be fixed in the operating system because this only happens when it does an improper TLB invalidation. ;)

EDIT: Refer to the first page of this thread...

---

So is Microsoft going to release a Windows Update for this as well? How does it work..

Quote:

---

Originally Posted by AuDioFreaK39

So is Microsoft going to release a Windows Update for this as well? How does it work..

---

i doubt anyone is going to release anything. The same clarification is in the C2D 65nm errata since April 2007.

Have you seen any bios updates for C2 regarding to this "bug"? ;)

since none of the reviewers found anything wrong with the chips , and i havent heard about instability or Bsods , makes me think its a minor issue with no real world effect..

Quote:

---

Originally Posted by justapost

So this bug is fixed with an bios update. Soemhone here compared a fixed with an unfixed bios? I don't think so.

---

I think there isn't any difference at all... no performance penalty with this one.. ;)


By the way...

Here's the page of the desktop Core 2 Duo E7000 and E8000 series: http://download.intel.com/design/pro...pdt/318733.pdf

It has the exact same text written on page 47.

Here's the page of the desktop Core 2 Duo X6800, E6000 and E4000 series: http://download.intel.com/design/pro...pdt/313279.pdf

It has the exact same text written on page 71.

Here's the page of the desktop Pentium Dual Core E2000 series: http://download.intel.com/design/pro...pdt/316982.pdf

It has the exact same text written on page 59.

Here's the page of the Intel Celeron 200 series: http://download.intel.com/design/pro...t/31854702.pdf

It has the exact same text written on page 53.

Maybe FUD will wanna post about all of them? :rofl:

Thanks for the refresh Ghostbuster. Looks like my respect for Fud just went down another point.

Say what you want about Fuad, i've always liked that he seems to be unbiased :yepp:

He writes just as much nonsense about Intel as he does about AMD, and same with ATI/NV :rofl::up:

The non-discriminating Baztard.

Quote:

---

Originally Posted by Katzenschleuder

Why?

---

Well I posted in rush, I've been thinking not of "a TLB bug" but "the TLB bug".
It would be extremely unlikely that both companies made the same mistake. Especially that Intel knew of AMD's problem.

Quote:

---

Originally Posted by Katzenschleuder

The whole hype around AMDs TLB bug was just another demonstration on how the common IT consumer web community lacks respectable wisdom.

---

IMO the hype was caused by the way AMD handled the problem - they shipped flawed review samples to get better benchmark scores.

Quote:

---

Originally Posted by m^2

Well I posted in rush, I've been thinking not of "a TLB bug" but "the TLB bug".
It would be extremely unlikely that both companies made the same mistake. Especially that Intel knew of AMD's problem.

IMO the hype was caused by the way AMD handled the problem - they shipped flawed review samples to get better benchmark scores.

---

Huh ??

AMD's problem was huge compared to this nitpickin an errata list.AMD's problem was that K10 failed validation at major OEMs , that's HP,IBM,Fujitsu,etc.When that happens you're royally screwed.Those major OEMs didn't want to touch K10 with a 10 ft pole.
When you ship servers in mission critical areas ( industry, banking,etc ), a once in a while system crash ( which wasn't so rare in virtualized environments it seems, which btw is the current hottest trend ) is simply not acceptable.

Chips can have hundreds of errata , as long as they pass the most stringent validation requirements you're fine.
The difference is that with K10 people in the industry started whispering and gossip sites picked it up ; in this case a dude searched an errata list ( guess what genius, that's published after validation => wasn't considered a game stopper ) and sent a link a FUD.

Next rumor by FUD: "Next Nehalem stepping will be 10% faster due to TLB bug fix".

Can't get the point why people are wasting their time reading FUD.

Quote:

---

Originally Posted by savantu

Huh ??

AMD's problem was huge compared to this nitpickin an errata list.AMD's problem was that K10 failed validation at major OEMs , that's HP,IBM,Fujitsu,etc.When that happens you're royally screwed.Those major OEMs didn't want to touch K10 with a 10 ft pole.
When you ship servers in mission critical areas ( industry, banking,etc ), a once in a while system crash ( which wasn't so rare in virtualized environments it seems, which btw is the current hottest trend ) is simply not acceptable.

Chips can have hundreds of errata , as long as they pass the most stringent validation requirements you're fine.
The difference is that with K10 people in the industry started whispering and gossip sites picked it up ; in this case a dude searched an errata list ( guess what genius, that's published after validation => wasn't considered a game stopper ) and sent a link a FUD.

---

I might be mistaken here, but I remember that they passed validation after disabling L3, didn't they?

Quote:

---

Originally Posted by m^2

I might be mistaken here, but I remember that they passed validation after disabling L3, didn't they?

---

Major OEMs started shipping K10 servers only with the B3 stepping.

Considering every processor has faults and that Core 2 was just the same, I see no problem here.

Do any of the older people here (35+) remember being taught in school that computers don't make mistakes, people do. Hmmm, I guess those teachers were very wrong.

Quote:

---

Originally Posted by freeloader

Do any of the older people here (35+) remember being taught in school that computers don't make mistakes, people do. Hmmm, I guess those teachers were very wrong.

---

People make computers, and people are not perfect : computers are not perfect.

Nope. The designer or human made the mistake. The computer is doing what it was designed to do.

edit - Zucker beat me to it.

http://download.intel.com/design/mob...pdt/320121.pdf - page 52
http://download.intel.com/design/pro...pdt/318733.pdf - page 47
http://download.intel.com/design/pro...pdt/313279.pdf - page 71
Just compare and see.
This TLB bug issue just doesn't exist and there won't be any BIOS fixes...

Found with xoqolatl, who ehen have written some small news about that ;)

Quote:

---

Originally Posted by Ghostbuster

"isles" or "aisles"? :D

Anyway, which reminds me http://www.theinquirer.net/en/inquir...l-ceo-confirms Charlie in the bunny suit is much funnier... :rofl: :ROTF:

---

Quote:

---

I identified myself and the publication, The INQUIRER, now partially owned by the Carlyle Group, [...]

---

huh, didn't know that.

Quote:

---

Originally Posted by kl0012

How does FUD assume that this is a bug? In the linked document it is labeled as "clarification", not errata.

---

It's a disease of the lobe of the brain that controls cognition and reasoning. They don't have a name for it yet, and there is no cure, but I'm sure scholars are studying it. Maybe they will find a cure one day. :ROTF:

Nehalems do not have TLB bug :) ... FUD is just being ordinary, posting BS ... :shakes:

http://www.guru3d.com/news/core-i7-has-a-tlb-bug-/

Quote:

---

Core i7 has a TLB bug ?
By Hilbert Hagedoorn, December 2, 2008 - 5:18 PM




Yikes .. it's a deja-vu as the same thing happened with AMD's Phenom processors. The colleagues over at Fud Zilla reported that Nehalem procesors has a Translation Lookaside Buffer bug. Intel actually 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 here, on page 37 AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS (TLBS) Invalidation part, you will see that Intel says that in some rare cases improper TLB invalidation may result in unpredictable system behavior and can hang your OS or result with incorrect data.

"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."

The BIOSes to workarround the TBL bug already are in place and it seems that this fix has very little effect on overall performance. AMD at the time simply switched off the entire TBL, and as to what Intel precisely did to address the issue .. is not yet known.

The BIOS update was issued on 14-11-08, before the products actually hit retail. In Intel's defense, so far everything we tested .. was 100% stable and extremely fast. But we'll report more once we hear more.

---

Closed...