Critical update for Intel Core CPUs is out

[dmens]

Ignorance, probably. OCing fanboys aren't the only people who use computers - some people actually do real work using CPUs, and CPU vendors have to spend tremendous resources ensuring that CPUs work correctly for the people who don't consider "passes prime95 for 24 hrs, but occasionally programs crash" stable. When bugs are found, those resources are put to use to provide fixes that don't introduce new bugs. It's not like Intel is the only company that makes mistakes either - this post covers a situation where AMD did something similar.

amen to that. everyone needs to take a step back here, whatever this fix is, there is a 100% chance it will not fix some blue screen that occurred during some random pseudo-stable test run while a 4300 overclocking to 3.xx ghz.

my personal guess on the nature of the fix is some sort of metastability issue on some TLB or L1 array circuitry, im far too lazy to find out for real lol. anyways, future BIOS versions will most likely include it.

 

[NoobyDoo]

Intel explains the Core 2 CPU errata
Briefly,

The errata itself has something to do with Translation Lookaside Buffers, also known to this world as TLB, part of the microarchitecture that is improving access to system memory as much as possible by keeping refences to physical memory in its own table.

After the errata was posted, Intel partners were informed that a fix is on the way. Later, Intel pushed out a microcode update in a form of BIOS update to its hardware partners, and there are already a lot of products in the channel with correct BIOSes from the start. For others, updating your BIOS with a newer version will apply the hotly debated update.

 

[HopJokey]

This post on XS I saw seems to clear things up a bit:

From http://www.realworldtech.com/f....readid=80534&roomid=2

Originally Posted by Linus Torvalds
Matt Sayler (sayler@thewalrus.org) on 6/27/07 wrote:
>
>How significant were the TLB handling changes?

I'd say: "Totally insignificant".

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

>In general, do Core2 chips seem to be more or less buggy
>than previous iterations? Are errata par for the course
>as we approach billion-transistor commodity MPUs?

Pretty much all CPU's have always had errata, and the
commodity CPU's usually have much fewer of them than the
boutique ones.

So this has nothing to do with billion-transistor MPU's,
or about commodity. CPU's always have bugs. And embedded
(or vendor-specific) CPU's tend to actually have more of
them, since they are often easier to work around by just
saying "don't do that, then".

So Intel and AMD actually tend to fix the bugs a lot more
aggressively than you'd see for some single-vendor thing,
simply because they don't control the stack the way other
architectures generally do.

I'd expect other CPU's to generally have more errata
than most commodity x86 chips.

Linus

 

[NoobyDoo]

OpenBSD founder Theo de Raadt on outstanding, fixed, and what he deems as "non-fixable bugs."

These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.
...
- We bet there are many more errata not yet announced -- every month
this file gets larger.
- Intel understates the impact of these erraata very significantly.
Almost all operating systems will run into these bugs.
- Basically the MMU simply does not operate as specified/implimented
in previous generations of x86 hardware. It is not just buggy, but
Intel has gone further and defined "new ways to handle page tables"
(see page 58).
- Some of these bugs are along the lines of "buffer overflow"; where
a write-protect or non-execute bit for a page table entry is ignored.
Others are floating point instruction non-coherencies, or memory
corruptions -- outside of the range of permitted writing for the
process -- running common instruction sequences.
- All of this is just unbelievable to many of us.

But also note :

(While here, I would like to say that AMD is becoming less helpful day
by day towards open source operating systems too, perhaps because
their serious errata lists are growing rapidly too).