'Intel Core-Duo has 34 bugs in it'

[Diasper]

From DailyTech

Intel Counts 34 Bugs in Core Duo

While some bugs appear to be more severe than others, Intel is still busy testing the Core Duo despite shipments already going out

Reports are circulating about Intel's latest Core Duo processor which has been shipping to customers with known bugs that were left unaddressed -- a total of 34 so far. However, this is somewhat typical for hardware as there are always bugs in devices such as CPUs, core-logic processors and even GPUs.

Most of the time, manufacturers such as Intel and AMD perform exhaustive testing on products long before any ship date is announced. This usually allows time for correction. Also, most of today's large designs go through testing on virtual systems, in which the actual logic is tested and corrections can be made quickly.

Some of the errors in the list so far can be corrected via software workarounds such as those found in firmware updates, but some appear to be more severe than others. The previous incident where processor bugs were well publicized occurred in Intel's first Pentium processors and was a mathematical division error. Intel's Pentium 4 architecture has a total of 64 bugs and while that may seem like a lot, they have not negatively affected the processors.

Intel will be updating its list of errors for Core Duo on a monthly basis, so only time will tell if we will have another Pentium 60/66 debacle.

Further news/specific from geek.com

 

[Diasper]

From user comments on geek.com on some specific bugs and possibly effects:

GoatGuy (6:19pm EST Mon Jan 23 2006)

You need to read the full PDF to get the entire gist of what can happen.

AE1 - It's a showstopper because, according to Intel's errata, page 13: "This is a rare condition that may result in a system hang."

"AE2 - only intentionally bad code can produce the 'overflow/wrap to zero' issue. No real code EVER exploits such wrapping. Further the error isn't an error per se: the code continues to run."

Are you suggesting then that there should never be facilities added to the processor to check for incorrect things? If only code that's not intentionally bad should be executed, then why have a #GP at all? Surely the operating system will prepare everything properly, right?

The processor needs to identify everything that is attempted outside of the visible ISA and "system state" presented at the software-end of the equation. Anything else, and your processor is nothing more than a "it will work if everything is okay" boat anchor (granted, for a very small boat).

"AE3 - is an alert"

AE3 is a *POTENTIAL* showstopper if only because not all operating systems allow single-step debugging when debuggers are not present or attached to the executing task/process.

"AE4 - would be a 'run-away' string copy. Bad code again, in any case."

Not at all. You, as the application running at any given time, have no idea where your physical memory maps to. You can cross page boundries with legal code and have no idea that it's happened. This is one of the advantages of using the x86 protected mode model for software development. For the application, that stuff is completely transparent. This is definitely a CPU error.

"AE5 - only of concern to O/S authoring teams: they need to keep their A and D bits organized. The workarounds are trivial, and again contained in the O/S core."

The point is: The CPU should be able to deal with this issue. Suppose a kernel driver changes these bits by mistake, or even on purpose because other cores allow them to be out of order. In that case, the Core Duo could potentially hang, causing the entire system to go down, meaning lost data, crashed hard drives (due to uncommitted buffers not being flushed, thereby messing up the FAT or indexing tables), etc.

"AE6 - if bad X86 (we're talking pre 286 code) is executed and double-faults, it might not resume. So? All old x86 code should be 6-feet under by now, no?"

It's not just old code. There are reasons why people today would write virtual-mode 8086 code. And double-faults can happen without the actual software causing any problems. The OS could've moved some page out of memory, causing the first fault. When the fault handler is called, that page isn't present, resulting in a double-fault.

It's not always bad code which causes things to fault or double-fault. A properly written operating system would be able to handle both of those aforementioned conditions, but if the processor intervenes and screws it up... that's the ball game. We should expect more from our cores.

"AE...9 - as you say "any programmer coding this..." and I agree. Intentionally obscure 'near-buggy' coding is hardly expected to have clean cut-aways."

It makes no difference. The processor should check everything to ensure that it's within that which Intel has dictated is available to the programmer. If it not within those parameters, then it should signal the appropriate fault.

"AE...12 - last I heard, no business software uses 'exact computation' flags to begin with. Some specialized math does, and especially some 'general purpose' equation fitters. Yet, the "probem" is a minimum of 16 decimal-places down. Combined with auto-extended 80-bit floating point, I don't think this is more than a "lab curiosity" rather than a "Show stopper"."

Again, the processor is not doing what Intel said it would do. It is an error, and it is something that someone, somewhere, at some point and time, could be relying upon. And if they do, the Core Duo will fail them.

"I just don't think any of these are going to affect "normal code", even at the very early stage. Intel has bigger fish to fry, just like AMD."

Then you haven't thought the matter through, or don't know what's involved in writing an operating system or applications programs because the things on this list of errata can affect any program, not just buggy ones.

There are a tremendous number of "constants" which must be relied upon from an OS point of view. Deviate any of those and, without knowledge of the deviation based on the model, significant problems can occur.

- by RickGeek

However, it seems probable that it'll just cause headaches for the programmers and end users shouldn't be affected...

Still with the resources Intel has this shouldn't really be happening...

 

[Diogenes2]

Look here for 131 bugs ( errata ) that exist in AMD 64 and Opteron processors...

http://www.amd.com/us-en/assets/content...e/white_papers_and_tech_docs/25759.pdf

Starts on page 13..


The documents shows which problems have been fixed while many just say " no fix planned "..

Nothing unusual about this..

 

[Link]

Originally posted by: Diogenes2
Look here for 131 bugs ( errata ) that exist in AMD 64 and Opteron processors...

http://www.amd.com/us-en/assets/content...e/white_papers_and_tech_docs/25759.pdf

Starts on page 13..


The documents shows which problems have been fixed while many just say " no fix planned "..

Nothing unusual about this..

But only 11 of those apply to the latest core revision.

 

[Diogenes2]

Originally posted by: Link
But only 11 of those apply to the latest core revision.

I'm sure that makes everyone who has the earlier revisions feel better..

 

[pm]

All processors ship with bugs. On the bright side, at least Intel documents the bugs - it's actually a fairly rarely practice in the IC industry - or even the tech industry. Normally in the rest of the industry, they are documented only after they are fixed.

 

[Diogenes2]

Originally posted by: pm
On the bright side, at least Intel documents the bugs -

You did notice the document I linked to didn't you ?



( Not an AMD ( or Intel ) employee .. )

 

[Cooler]

come on every thing have bugs in it we are lucky for that tranister count it has that few it like one every ten million tranisters. You have better shot at winning the lotto then creating a chip with no bugs.

 

[pm]

Originally posted by: Diogenes2

Originally posted by: pm
On the bright side, at least Intel documents the bugs -

You did notice the document I linked to didn't you ?



( Not an AMD ( or Intel ) employee .. )

Yeah, AMD does as well. I guess I should have said, "at least both Intel and AMD document bugs" - although my comment was towards the original poster.

Still, when you take a couple of steps back and think about it, it's fairly rare in the tech industry to document bugs... there are not that many companies that do it. For example, for something like a network wireless router, I get documents when they fix bugs, but not that they exist unless they are really blatant. Same for software. And most IC company's don't mention bugs at all unless they are very severe. How much of a bug list did you get with your cable modem, your network router, your video card.... we all know they have bugs, but no one talks about them.

 

[RichUK]

Will these bugs be that detrimental? I?ve just ordered a laptop for my farther, it?s a DELL laptop using the T2400 Core Duo. I hope we don?t get any problems with it, as I don?t know how significant these problems will be.

 

[dmens]

A lot of these bugs won't matter unless you debug (e.g. LBR). Some of them no one outside intel will ever see (emon/perfmon). One of them I don't even think should be called a bug (AE21). Even then most of these are extreme corner cases or bad code...

Can't say if there will be a problem running worldly software, but then again, if they released yonah, I am sure they took all issues into account.

 

[dexvx]

The odds of an everday user being adversely affected by these bugs is probably akin to winning the lottery jackpot.

 

[RichUK]

The thing that worried me having not heard of these in the open bugs before, was:

AE1 - It's a showstopper because, according to Intel's errata, page 13: "This is a rare condition that may result in a system hang."

Although being rare, how rare is classed rare. The way i looked at it (although a bit naive considering the size and rep of Intel), is this is a new architecture to Intel, and it would be kind of a tester period between now and Merom/Conroe to iron out these somewhat insignificant bugs. Well the laptop is already ordered so i'll have to see when it comes through, either way i didn?t pay for it

 

[dmens]

Rare enough such that it was deemed not worth the effort to fix despite having available steppings. Basically war room or validation leads figure the chance it will affect the average user is nil.

By the way, with the except of sleep states and some dual core related issues, those bugs deal with existing uarch. We've been receiving pushed bugs from yonah and a lot of them were waived for us, and chances are merom waived them as well.

 

[ShadoWing]

wow...talk about not getin ur money's worth

 

[bersl2]

These bugs get worked around in compilers. You only need to worry if you're programming one of those or in assembly.

 

[FelixDeCat]

Originally posted by: ShadoWing
wow...talk about not getin ur money's worth

Especially with AMDs 131 bugs! Sheesh!

 

[BrownTown]

lol, bugs in the debugging circutry, thats so ironic...

 

[carlosd]

Originally posted by: FelixDeKat

Originally posted by: ShadoWing
wow...talk about not getin ur money's worth

Especially with AMDs 131 bugs! Sheesh!

You forgot to say...actually only 11 in the last revision.
FelixDeKat is a bug of nature...non-fixable:laugh:

 

[DAPUNISHER]

Yet again, thank you to the Intc employees who always give a good tech based explanation for us laymen. Some would over-inflate the significance of the errata, so solid info is much appreciated

 

[dexvx]

Originally posted by: carlosd

Originally posted by: FelixDeKat

Originally posted by: ShadoWing
wow...talk about not getin ur money's worth

Especially with AMDs 131 bugs! Sheesh!

You forgot to say...actually only 11 in the last revision.
FelixDeKat is a bug of nature...non-fixable:laugh:

So according to you, all the people who bought early revision A64's are boned?

 

[carlosd]

The document actually only describes around 70 bugs and not all applicable to the same revision (only around 45 applicable to the AH-B3 revision, launch date: sept. 23th, 2003), but there is felixthekat trolling without having reading the document. anyway aren't those errors transparent for the final user?? I have used 754 A64s(clawhammer and newcastles) and used to debug for a long time and they run absolutely flawlessly: no strage errors, no lockups, no blue screens, no reboots....so those bugs were pretty light, the core duo bugs seems to be pretty serious...but I think that's normal in the "very first revision".

 

[FelixDeCat]

Originally posted by: dexvx

Originally posted by: carlosd

Originally posted by: FelixDeKat

Originally posted by: ShadoWing
wow...talk about not getin ur money's worth

Especially with AMDs 131 bugs! Sheesh!

You forgot to say...actually only 11 in the last revision.
FelixDeKat is a bug of nature...non-fixable:laugh:

So according to you, all the people who bought early revision A64's are boned?

He was quite obviously trying to troll me.

 

[TuxDave]

Originally posted by: carlosd
The document actually only describes around 70 bugs and not all applicable to the same revision (only around 45 applicable to the AH-B3 revision, launch date: sept. 23th, 2003), but there is felixthekat trolling without having reading the document. anyway aren't those errors transparent for the final user?? I have used 754 A64s(clawhammer and newcastles) and used to debug for a long time and they run absolutely flawlessly: no strage errors, no lockups, no blue screens, no reboots....so those bugs were pretty light, the core duo bugs seems to be pretty serious...but I think that's normal in the "very first revision".

What type of debug are we talking about?

 

[carlosd]

Originally posted by: FelixDeKat

Originally posted by: dexvx

Originally posted by: carlosd

Originally posted by: FelixDeKat

Originally posted by: ShadoWing
wow...talk about not getin ur money's worth

Especially with AMDs 131 bugs! Sheesh!

You forgot to say...actually only 11 in the last revision.
FelixDeKat is a bug of nature...non-fixable:laugh:

So according to you, all the people who bought early revision A64's are boned?

He was quite obviously trying to troll me.

You are obviously trying to troll all the forum!