i7 has a TLB BUG

I don't get why it's funny.

The Core 2 architecture had one as well.
 
Even if this is true, Intel did handle the situation better than AMD by releasing a consumer part first before a server part. Normally a server part would be tested more thoroughly than a consumer part. By releasing a consumer part first, Intel can secretly release a new stepping with the fix for the server. Just like AMD, I doubt that this bug will affect most consumer.
 
It only mattered in AMD's case because it was blown completely out of proportion and they made the patch mandatory in Vista Service Pack 1 which killed performance.
 
I wonder if it actually manifests it's self in reality, like the AMD TLB errata did...
 
It'll be interesting to see if Microsoft will force a TLB patch onto users like it did with SP1 for Vista. Owners that had the early Phenoms noticed huge performanc decreases after SP1 was released and they found out Microsoft forced the TLB off even though users had it enabled in the motherboard's bios. You think Microsoft will treat Intel this way? Yeah right :rolleyes:
 
Digital Viper-X- said:
why don't you find it funny :p I find it hilarious!
Click to expand...

Why? Is this supposed to be some sort of relational humor to the Phenom TLB? Intel has had errata in all their processors, including TLB errata. I wouldn't be surprised if the Core 2 had more errata overall than the Phenom. Pages 10 through 14 of this specification document are errata of which many are still unfixed on the 45nm Core 2 architecture.

Diseaseboy said:
It'll be interesting to see if Microsoft will force a TLB patch onto users like it did with SP1 for Vista. Owners that had the early Phenoms noticed huge performanc decreases after SP1 was released and they found out Microsoft forced the TLB off even though users had it enabled in the motherboard's bios. You think Microsoft will treat Intel this way? Yeah right :rolleyes:
Click to expand...

Please at least google before you post. There are forced patches for Intel processor errata all the time. An example that effects all Core 2 processors is KB936357.
 
it's funny because the reaction alot of fanbois will have to the article(from both amd and intel camps)
 
First i was shocked.. then i read the specification updates for all C2D and C2Q models and they're all 'suffering' the same 'bug'.
 
MrMike said:
Why? Is this supposed to be some sort of relational humor to the Phenom TLB? Intel has had errata in all their processors, including TLB errata. I wouldn't be surprised if the Core 2 had more errata overall than the Phenom. Pages 10 through 14 of this specification document are errata of which many are still unfixed on the 45nm Core 2 architecture.



Please at least google before you post. There are forced patches for Intel processor errata all the time. An example that effects all Core 2 processors is KB936357.
Click to expand...

Not the same thing...you have the ability to uninstall a seperate update if you want to, plus it does not substantially affect the performance like the AMD fix does. Microsoft forces the AMD tlb fix on you and you have to use a third party hack to disable it.
 
Couldn't care less, either way how would it effect the average user, you'd have to be crunching some pretty serious calculations in order for the bug to show up, you won't get it playing Counter Strike or Fall Out 3.
 
glarsen84 said:
First i was shocked.. then i read the specification updates for all C2D and C2Q models and they're all 'suffering' the same 'bug'.
Click to expand...
Yeah, this is an old "bug." Intel changed TLB handling a while back and it affects operating systems that incorrectly set the values. I don't think any current OSs in use are affected by this.

From 16 months ago, the last time the change came up: http://www.hardforum.com/showpost.php?p=1031202262&postcount=36 The post also has details of what was changed.

RWT thread on this "bug" said:
Name: Linus Torvalds ([email protected]) 6/27/07

Matt Sayler ([email protected]) on 6/27/07 wrote:
>
>How significant were the TLB handling changes?
I'd say: "Totally insignificant".
Click to expand...
 
Diseaseboy said:
Not the same thing...you have the ability to uninstall a seperate update if you want to, plus it does not substantially affect the performance like the AMD fix does. Microsoft forces the AMD tlb fix on you and you have to use a third party hack to disable it.
Click to expand...

How do you uninstall a separate update from a service pack if you want to?

KB936357 is included in Windows XP Service Pack 3 and Windows Vista Service Pack 1.
 
alg7_munif said:
By releasing a consumer part first, Intel can secretly release a new stepping with the fix for the server. Just like AMD, I doubt that this bug will affect most consumer.
Click to expand...
This is a new behavior, not a "bug." It's not going to be fixed since it's not broken. See the discussion in my post above. It doesn't affect any current OSs in use, and it does not affect performance.

AMD's TLB bug was caused by certain bit conditions and timing, and led to repeatable crashes with virtualization workloads. Desktop users may have had far fewer problems, but you can see from the AMD recommended BIOS patch that they wanted to be safe by forcing the work-around.
 
Digital Viper-X- said:
LOL!
http://www.fudzilla.com/index.php?option=com_content&task=view&id=10707&Itemid=1
-->
http://download.intel.com/design/processor/specupdt/320836.pdf
well intel seemed to have confirmed it in their

I know it's fudzilla, I just thought it's funny and it seems to be in their spec sheet ^^ Not sure which one it is though as I didn't have time to read it all =p
Click to expand...

you really needed to quote this

"
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 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. Here is the word to word quote: "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.""

all i can say is i hope this damages intel as much as it damaged amd this is so damn funny lol
 
maxius said:
all i can say is i hope this damages intel as much as it damaged amd this is so damn funny lol
Click to expand...
The TLB invalidation change has been around since Core 2 was released over 2 years ago. Is Intel destroyed yet? :p Like I mentioned twice above, there doesn't seem to be any current OS affected by this. This is a very different problem than the AMD B2 TLB bug (with certain bits set fails to update) and doesn't cause any performance decreases.

Sorry, Charlie.
 
improper TLB invalidation
Click to expand...

Doesn't that mean the OS has an error in it for this bug to manifest itself? As opposed to AMD's bug, which just happens to you anyway? Yea, no difference there... :rolleyes:
 
devil22 said:
Doesn't that mean the OS has an error in it for this bug to manifest itself? As opposed to AMD's bug, which just happens to you anyway? Yea, no difference there... :rolleyes:
Click to expand...
The problem is that Conroe introduced a change and some system developers felt it wasn't documented well enough. The problem isn't really the OS's fault, it was a documented change of behavior.

Linux wasn't affected by it at all according to Linus Torvalds, but I think I remember Theo De Raat complaining about it. I don't remember any particular patch for Windows being made either. That doesn't mean XP SP0 (for example) isn't affected, but the only supported version at Conroe's release was SP1 (or higher) and a few months later only SP2. SP2 may have included any necessary changes... or possibly Windows wasn't affected either.
 
pxc said:
The problem is that Conroe introduced a change and some system developers felt it wasn't documented well enough. The problem isn't really the OS's fault, it was a documented change of behavior.
Click to expand...

Yes, but some people are (predictably) acting like this is the same as the AMD bug. But in this case, 1. it was just a documented change of behaviour and 2. the 'fix' did not kill performance.
 
All processors and computer components in general suffer from some kind of errata. Unfortunately the errata for AMD processors reads like a horror novel. The Intel errata is boring by comparison. At least that has always been my experience. I haven't read anything in regard to errata on the most recent processors. So I'm just going on past knowledge here.
 
This was in an email sent from intel over on techreport.com:
The "AAJ1 Clarification of TRANSLATION LOOKASIDE BUFFERS" document is a SPEC CLARIFICATION, and is simply a pointer to a previous document written in April 2007.
SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs. There are errata on the Intel® Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch.
Click to expand...

Since it was fixed prior to the Core i7 launch, there is no chance of a future update [related to this] killing Core i7 performance.
 
devil22 said:
This was in an email sent from intel over on techreport.com:


Since it was fixed prior to the Core i7 launch, there is no chance of a future update [related to this] killing Core i7 performance.
Click to expand...

I just wanna add more fuel to the fire :D

Firstly, Intel said that the bug is fixed prior to the launch, so nobody really know about the "real Core i7 performance" without the fix. Maybe the fix did cost some performance hit but nobody except for the inside people really know about it. The Core i7 could be much faster without the fix, just think about it, Intel did a major architecture change with the Core i7 but it is really only 10-20% faster clock for clock than the C2Q?

Secondly, the only difference I see between this and the AMD bug is when AMD had the bug, it was blown way out of proportion. Intel did better when handling the issue than AMD. Intel found the problem earlier and they managed to fix it before it was out. What I do know is AMD found out about the problem quite late and even when they managed to come out with a fix, the issue was already blown way out of proportion across the globe.

With that said, flame on :D
 
alg7_munif said:
I just wanna add more fuel to the fire :D

Firstly, Intel said that the bug is fixed prior to the launch, so nobody really know about the "real Core i7 performance" without the fix.
Click to expand...
Well, we know that the "fix" did nothing to performance on Core 2 when it was patched in April 2007. How does it follow that somehow Core i7 is any different?

Your problem is that you're trying to equate both Intel's and AMD's problem and fix. Two separate problems, two separate fixes. Intel seemed to work around it with no performance penalty... AMD not so much. :p
 
Yes, not all TLB bugs are created equal. Some people see 'TLB bug' and think that it is the same as every other 'TLB bug', I'm not a chip expert but it is quite likely that many potential problems with the TLB do not require performance costing fixes, and some do. AMD's was one that took a hit on performance, intel's probably was not, since the Core 2's had this problem patched last year and nobody noticed anything, and the Core i7's are still much faster than the Core 2's which are in turn much faster than the AMDs. If AMD fixed their TLB bug and the performance was still better than the competition, nobody would have cared about that either, but when you're slower than the competition, and you have to issue a fix that costs 20% more performance, then it's a big deal.. what's so hard to understand about that? Acting like there is an intel bias when 99% of people think big companies eat babies for breakfast is just bizaare.
 
pxc said:
Well, we know that the "fix" did nothing to performance on Core 2 when it was patched in April 2007. How does it follow that somehow Core i7 is any different?

Your problem is that you're trying to equate both Intel's and AMD's problem and fix. Two separate problems, two separate fixes. Intel seemed to work around it with no performance penalty... AMD not so much. :p
Click to expand...

So you know how well the Core i7 performs without the fix? Core i7 and Core 2 have a very different architecture, I would say the Core i7 is actually more similiar to the Phenom than to the Core 2, except for the performance obviously. ;)

I don't need to upgrade my C2Q just yet but now I have one more reason to wait for the Core i7 refresh. Maybe the refresh would give a better performance increase than what the 45nm C2Q gave. :D

Btw from what I can understand, there are actually two different issues here:
1) SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs.

2) There are errata on the Intel® Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch.
Click to expand...
 
Gee, 'TLB' seems like such a red flag to some people.
Firstly, it's not even a bug. It's well-defined behaviour, just slightly different from how certain OSes used to handle it.
Secondly, even if there is a bug in a processor, it's not necessarily a disaster. Modern CPUs can be updated with microcode from the BIOS (or the OS), which in most cases can fix bugs. So even if you have a 'bugged' processor, once you've installed the fix in your BIOS (or as an OS patch), your CPU will work fine.

The big deal with AMD's TLB bug was that it couldn't really be fixed other than just bypassing the TLB altogether, causing a big performance hit. Not all bugs are like that, not even TLB bugs, since both Core2 and Core i7 have had microcode updates relating to the TLB, with no impact to performance.

Oh, and it's sad that even people like Theo Valich still can't get the name right.
It's a Translation Lookaside Buffer (it's a cache that stores addresses translated between physical and logical address spaces, how hard is it to understand? 'Transition', huh? A transition of what to what? How does that even make sense?).
 
Scali2 said:
Gee, 'TLB' seems like such a red flag to some people.
Firstly, it's not even a bug. It's well-defined behaviour, just slightly different from how certain OSes used to handle it.
Secondly, even if there is a bug in a processor, it's not necessarily a disaster. Modern CPUs can be updated with microcode from the BIOS (or the OS), which in most cases can fix bugs. So even if you have a 'bugged' processor, once you've installed the fix in your BIOS (or as an OS patch), your CPU will work fine.

The big deal with AMD's TLB bug was that it couldn't really be fixed other than just bypassing the TLB altogether, causing a big performance hit. Not all bugs are like that, not even TLB bugs, since both Core2 and Core i7 have had microcode updates relating to the TLB, with no impact to performance.

Oh, and it's sad that even people like Theo Valich still can't get the name right.
It's a Translation Lookaside Buffer (it's a cache that stores addresses translated between physical and logical address spaces, how hard is it to understand? 'Transition', huh? A transition of what to what? How does that even make sense?).
Click to expand...
I love it when you downplay the bug on the Core i7. It is not even a bug? It is a well-defined behavior? Lol, it is a bug but it has been fixed, whether the fix has an impact to the performance or not, nobody really knows because unlike Phenom, you can't disable the fix on Core i7 and the bug on Core i7 was fixed before the CPU was released.

I just hope that your attitude towards the bug on Phenom was the same like you attitude towards Core i7:
Scali2 said:
I'm just trying to inform people about the risks, because this thread makes it painfully obvious that most of you haven't the slightest idea what kind of bug this is, and what the consequences will be when it strikes.
I think everyone needs to have a clear idea about the consequences before they decide to buy a 'risky' CPU such as this one.
And for the ones who already bought one, they should be aware of the consequences of running it without fix aswell.



I know that. What you and all those other **** in this thread don't realize is the difference in *severity* of the bugs.
There have been very few CPUs in the history of computing that had a bug as severe as this one. The closest example that comes to mind is the Pentium FPU bug. Ofcourse Intel did a total recall on that one, much better than this performance-sucking TLB fix.



What do you want to say with that post?
Haven't you people ever been to school? Don't you know anything about scientific research and statistics? Again I would like to point you to Popper.

Just stop arguing when you **** don't have any idea what you are talking about. Go ask someone else who really understands the bug, such as dexvx, and they'll say the same as me.
All you guys are doing is arguing that I'm wrong when the facts and explanations are right there, staring in your face. You just don't understand them. That's just really dumb, if you ask me.
You're basically insulting and harassing me because you don't want to believe what I'm saying, and are not capable of understanding it yourself and making your own analysis of the situation. You're just borrowing third-party opinions, and you happen to select the one that suits your agenda. I have no other word for it but dumb. People like you don't belong on a tech forum. You're not talking about technology, you are just about emotional hangups about brands and products, not backed up by facts, but by irrational 'gut feelings'. Go away.
Click to expand...
 
The document that is referred to (the one from 2007) is a spec update. TDPs work slightly differently on Core2 and Core i7 than on previous architectures. This is NOT a bug, it is well-defined behaviour.

Aside from that, Intel made some slight changes to both the Core2 and Core i7's microcode, some of which related to the TLB.

And since Intel already made these changes prior to release, it will not affect any customers, unlike with the Phenom. Customers will simply buy the exact same CPU that reviewers have used, unlike the Phenom fix which robbed them of 10% or more performance. So the Nehalem will just perform to their expectations, unlike Phenom.

I find it highly unlikely that Nehalem suffers a significant performance loss from any of these changes (Intel has never before released any microcode update that made any impact on performance anyway). If it has the same impact on performance as the fix for Phenom had, then the unpatched Nehalem chips would really be inconceivably fast. I don't think Intel is that good. Nehalem is already better than I expected.

So no, I don't think the same attitude as with Phenom is called for here. It's a completely different situation. AMD just made a big mess of it, firstly by releasing a CPU without proper validation, and having to hear from an OEM that they ran into stability problems after the CPU was already in the sales channels. Secondly their fix hampered the performance of an already underperforming chip even more, making the CPU a very undesirable product, so basically you had to wait months for the next stepping if you wanted a decent Phenom.

With Nehalem the bugs were caught and fixed in time, and it is by far the fastest x86-class CPU ever made. So big deal that someone found the word 'TLB' in the errata months after it was fixed (well before release time). It's about as non-issue as you can get.
 
Scali2 said:
Gee, 'TLB' seems like such a red flag to some people.
Firstly, it's not even a bug. It's well-defined behaviour, just slightly different from how certain OSes used to handle it.
Secondly, even if there is a bug in a processor, it's not necessarily a disaster. Modern CPUs can be updated with microcode from the BIOS (or the OS), which in most cases can fix bugs. So even if you have a 'bugged' processor, once you've installed the fix in your BIOS (or as an OS patch), your CPU will work fine.

The big deal with AMD's TLB bug was that it couldn't really be fixed other than just bypassing the TLB altogether, causing a big performance hit. Not all bugs are like that, not even TLB bugs, since both Core2 and Core i7 have had microcode updates relating to the TLB, with no impact to performance.

Oh, and it's sad that even people like Theo Valich still can't get the name right.
It's a Translation Lookaside Buffer (it's a cache that stores addresses translated between physical and logical address spaces, how hard is it to understand? 'Transition', huh? A transition of what to what? How does that even make sense?).
Click to expand...

im pretty sure he knows what it is and it looks like a typo to me. lol. I think you're taking this way too seriously and are kicking up some unnecessay flames.
 
alg7_munif said:
I love it when you downplay the bug on the Core i7. It is not even a bug? It is a well-defined behavior? Lol, it is a bug but it has been fixed, whether the fix has an impact to the performance or not, nobody really knows because unlike Phenom, you can't disable the fix on Core i7 and the bug on Core i7 was fixed before the CPU was released.
Click to expand...


Your logic hurts me. So the current bench marked released Core i7's is bad because you cannot "turn off" said fix.

We know what the current performance is so who cares.
 
alg7_munif said:
I love it when you downplay the bug on the Core i7. It is not even a bug? It is a well-defined behavior? Lol, it is a bug but it has been fixed, whether the fix has an impact to the performance or not, nobody really knows because unlike Phenom, you can't disable the fix on Core i7 and the bug on Core i7 was fixed before the CPU was released.

I just hope that your attitude towards the bug on Phenom was the same like you attitude towards Core i7:
Click to expand...

Sorry , but you are clueless.

x86 had no clear policy with TLB page tables and caching, most were down right ( large SW vendors , some did a few hacks or implemented it badly by having poor information on the CPU side ).

Starting with Core Intel defined a standard , it changed the way its CPUs behaved , thus all of its future CPUs will adhere to it.It is not a bug , it is a f***ing clarification.

Linus Torvalds explains it nicely :

The biggest problem is that Intel should just have
documented the TLB behavior better. The Core 2 changes
are kind of gray area, and the old documentation simply
didn't talk about the higher-level page table structures
and the caching rules for them.

So that part is just a good clarification, and while it
could be called a "bug" just because older CPU's didn't
do that caching, I don't think it's an errata per se.

Of course, if you depended on it not happening (and a
lot of people did), it's painful. But it really does make
the architecture definition better and clearer.

(I don't think Linux needed any software changes at all for
the TLB semantics clarification, although that was largely
just due to luck - we had mis-used the TLB earlier, and
fixing that software bug we rewrote the page table handling
to be more robust, which means that the spec update from
Intel didn't affect us at all, afaik).
Click to expand...

http://realworldtech.com/forums/index.cfm?action=detail&id=80552&threadid=80534&roomid=2

All major OSes ( that is one owned by more than your drinking buddies ) has no problem ; as always , quality programming allows you to sit comfortably as things evolve.
 
Fuser said:
Your logic hurts me. So the current bench marked released Core i7's is bad because you cannot "turn off" said fix.

We know what the current performance is so who cares.
Click to expand...

What I want to say is we don't know whether the fix hurts the performance or not because we don't know what is the performance without the fix. Maybe the current BIOS fix hurts the performance like it did with Phenom. Maybe without the fix, Core i7 would be faster than what it is right now.

Maybe later a new refresh will come out with a fix in the silicon which will give a better performance like the B3 Phenom. I'm sure that Intel won't release a new batch of Core i7 like AMD did with Phenom.

Intel did much better than AMD when handling the issue. I'll wait for the Core i7 refresh just in case that it will gain more performance than the current Core i7 not from the core tweaks alone.
 
savantu said:
Sorry , but you are clueless.

x86 had no clear policy with TLB page tables and caching, most were down right ( large SW vendors , some did a few hacks or implemented it badly by having poor information on the CPU side ).

Starting with Core Intel defined a standard , it changed the way its CPUs behaved , thus all of its future CPUs will adhere to it.It is not a bug , it is a f***ing clarification.

Linus Torvalds explains it nicely :

http://realworldtech.com/forums/index.cfm?action=detail&id=80552&threadid=80534&roomid=2

All major OSes ( that is one owned by more than your drinking buddies ) has no problem ; as always , quality programming allows you to sit comfortably as things evolve.
Click to expand...
I don't know about you but from what I can understand from this Intel statement:
SPEC CLARIFICATION AAJ1 was initially added due to an issue on the Intel® Core 2 Duo processor which was previously corrected with a BIOS update; this issue does not impact the Nehalem Family of CPUs. There are errata on the Intel® Core i7 processor that relate to the TLB. These all relate to improper translations or error reporting, and all of those that impact functionality have been fixed via BIOS updates prior to Core i7 launch.
Click to expand...

There are actually two separate issues, 1) the SPEC CLARIFICATION AAJ1 and 2) the errata on Core i7 that relate to the TLB.
 
Exactly, thing is that the TLB behaviour that Intel eventually defined was slightly different from what Core2 originally did (probably because after consulting with various OS developers, they changed their minds on how it should work). Hence a microcode update was issued, to make sure all Core2 processors behaved as defined. Not really a bug as such. The TLB worked as intended before, and it works as intended after the spec update and microcode update.

Now with AMD, there was some kind of timing problem where there was a certain window where results written to the TLB wouldn't be read back properly. This caused stability problems, because you could be accessing the wrong memory. Apparently this problem occured somewhere deep inside some hardwired logic, and couldn't be fixed with just microcode, so they ended up bypassing the TLB altogether, which is what caused the performance hit.
 
You must log in or register to reply here.
Back
Top