Nehalem also has a TLB bug

Looks like having a TLB bug is becoming a right of passage for anybody
designing a quad-core processor with an L3 cache and an integrated
memory controller. AMD had it in it's first revision of Barcelona, and
now Intel has it in its first revision of Nehalem.

Yousuf Khan

"We were told 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 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."

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."
http://www.fudzilla.com/index.php?op...10707&Itemid=1

On Dec 1, 10:19*am, Yousuf Khan <bbb...@yahoo.com> wrote:
> Looks like having a TLB bug is becoming a right of passage for anybody
> designing a quad-core processor with an L3 cache and an integrated
> memory controller. AMD had it in it's first revision of Barcelona, and
> now Intel has it in its first revision of Nehalem.
>
The key sentence seems to be:

"Developers of operating systems should take this documentation into
account when designing TLB invalidation algorithms."

Quickly followed by

"For the processors affected, Intel has provided a recommended update
to system and BIOSvendors to incorporate into their BIOS to resolve
this issue."

In the case of the AMD bug, the issue was that the available
workarounds were costly (~10%) in terms of performance, which meant
that you had the unenviable choice between getting the performance
promised by early benchmarks or having a processor that wouldn't hang
unpredictably.

There is no clue in what you have offered, other than the situation
offers an amdroid the opportunity to say, "See, it happens to Intel,
too," as to whether this is a serious matter or merely a concern for
kernel and BIOS developers.

Robert.

On Dec 1, 4:38 pm, Robert Myers <rbmyers...@gmail.com> wrote:
> The key sentence seems to be:
>
> "Developers of operating systems should take this documentation into
> account when designing TLB invalidation algorithms."

Why is that key? AMD said the same thing.

> Quickly followed by
>
> "For the processors affected, Intel has provided a recommended update
> to system and BIOSvendors to incorporate into their BIOS to resolve
> this issue."
>
> In the case of the AMD bug, the issue was that the available
> workarounds were costly (~10%) in terms of performance, which meant
> that you had the unenviable choice between getting the performance
> promised by early benchmarks or having a processor that wouldn't hang
> unpredictably.

Until Intel provides those updated BIOSes, then we won't know if there
is a performance penalty as well. Besides in the case of AMD, the
Linux community came up with a workaround that had less than a 1%
performance penalty. The BIOS solution was less aesthetic, as it
turned off the L3 cache entirely to avoid the problem. In the Linux
solution, the kernel just checked for conditions that might cause the
problem, and took care of them when necessary without turning the L3
off.

> There is no clue in what you have offered, other than the situation
> offers an amdroid the opportunity to say, "See, it happens to Intel,
> too," as to whether this is a serious matter or merely a concern for
> kernel and BIOS developers.

What clue do you need Robert?

Yousuf Khan

On Dec 2, 2:56*am, YKhan <yjk...@gmail.com> wrote:
> On Dec 1, 4:38 pm, Robert Myers <rbmyers...@gmail.com> wrote:
>
>
> > There is no clue in what you have offered, other than the situation
> > offers an amdroid the opportunity to say, *"See, it happens to Intel,
> > too," *as to whether this is a serious matter or merely a concern for
> > kernel and BIOS developers.
>
> What clue do you need Robert?
>
Some actual indication of what the consequences of dealing with this
will be:

1. Nearly invisible to the end user.

2. Enough to cause the same kinds of marketing problems for Intel that
AMD encountered.

At this point, there just isn't enough information to distinguish
between 1 and 2, which is the only distinction that matters.

The fact that Intel has a bug in the same class as encountered by AMD
may in itself be interesting if it is anything but pure coincidence.
If it isn't pure coincidence; that is to say it is something that
Intel should have been especially careful about because of AMD's
experience, then one has to wonder yet again about the competence of
Intel management.

Again, though, there simply isn't enough information to conclude
anything, other than that Intel had a bug in the same class as AMD.
Whether or not that should concern anyone other than BIOS and kernel
developers remains to be seen.

Robert.

> The fact that Intel has a bug in the same class as encountered by AMD
> may in itself be interesting if it is anything but pure coincidence.
> If it isn't pure coincidence; that is to say it is something that
> Intel should have been especially careful about because of AMD's
> experience, then one has to wonder yet again about the competence of
> Intel management.
>
> Again, though, there simply isn't enough information to conclude
> anything, other than that Intel had a bug in the same class as AMD.
> Whether or not that should concern anyone other than BIOS and kernel
> developers remains to be seen.

Finally! A situation where potential problems show up just *before*
I buy a unit! I had an X58 motherboard, i7 CPU and triple-channel RAM
all picked out and was about to order when I saw this thread. If my luck
had been running as usual, I would have just installed the hardware *then*
this thread would've appeared. As you say it may not make any difference
at all but I'm glad I can wait and see if that turns out to be the case.

Tom Lake

On Dec 3, 8:20*am, "Tom Lake" <tl...@twcny.rr.com> wrote:

>
> Finally! *A situation where potential problems show up just *before*
> I buy a unit! *I had an X58 motherboard, i7 CPU and triple-channel RAM
> all picked out and was about to order when I saw this thread. *If my luck
> had been running as usual, I would have just installed the hardware *then*
> this thread would've appeared. *As you say it may not make any difference
> at all but I'm glad I can wait and see if that turns out to be the case.
>

Perhaps. If you're following amdroids scouring the news looking for
bad things to say about Intel, though, you may be on a fool's errand.

http://www.theinquirer.net/gb/inquir...ore-i7-tlb-bug

<quote>

"This is a spec clarification that points back to a programmer's
application note written by Intel in April 2007. The same spec
clarification is in our Penryn docs pointing to same app note, which
advises on programming techniques to avoid any issue", an Intel
spokesman told the INQ.

</quote>

IOW, this is old news, and the lead to the OP is misleading, to put it
kindly. Even The Inquirer can't spin it the way the OP apparently
wanted to.

Robert.

> "This is a spec clarification that points back to a programmer's
> application note written by Intel in April 2007. The same spec
> clarification is in our Penryn docs pointing to same app note, which
> advises on programming techniques to avoid any issue", an Intel
> spokesman told the INQ.

So why haven't they fixed it since April 2007?

Tom Lake

On Dec 3, 1:36*pm, "Tom Lake" <tl...@twcny.rr.com> wrote:
> > "This is a spec clarification that points back to a programmer's
> > application note written by Intel in April 2007. The same spec
> > clarification is in our Penryn docs pointing to same app note, which
> > advises on programming techniques to avoid any issue", an Intel
> > spokesman told the INQ.
>
> So why haven't they fixed it since April 2007?
>
Because, as far as Intel is concerned, apparently, it isn't a "bug"
that needs fixing. It's something that writers of OS's need to pay
attention to.

The idea that it's a "bug" is coming from the AMD misinformation
machine in evidence here.

Robert.

Tom Lake wrote:
> Finally! A situation where potential problems show up just *before* I
> buy a unit! I had an X58 motherboard, i7 CPU and triple-channel RAM
> all picked out and was about to order when I saw this thread. If my
> luck had been running as usual, I would have just installed the hardware
> *then*
> this thread would've appeared. As you say it may not make any difference
> at all but I'm glad I can wait and see if that turns out to be the case.

Murphy's Law plays a role in my life as well. :-)

Yousuf Khan

On Mon, 1 Dec 2008 23:56:15 -0800 (PST), YKhan <> wrote:

>
>Until Intel provides those updated BIOSes, then we won't know if there

Intel released a fix before launch, retail parts are fine.

Ed

>
> Yousuf Khan