Slashdot Log In
34 Design Flaws in 20 Days of Intel Core Duo
Posted by
CmdrTaco
on Tue Jan 24, 2006 11:26 AM
from the what-am-i-designing-this-now dept.
from the what-am-i-designing-this-now dept.
Pray_4_Mojo writes "Geek.com is reporting that Intel's errata (bug) documentation shows that the Intel Core Duo chip has 34 known issues found in the 20 days since the launch of the iMac Core Duo. (you can read the list) with only plans to fix one of them. While bugs in hardware is nothing new (the P4 has 64 known issues, at this time Intel does not plan to fix a single one) this marks one of the first times that Intel released a processor with known bugs, and some of the bugs are of higher severity than in the past. Also alarming is the rate the flaws have been found, at one and half per day since the launch of the iMac Core Duo."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Up front (Score:5, Interesting)
Re:Up front (Score:5, Insightful)
Time will only tell.
Parent
Re:Up front (Score:4, Informative)
For those still reading books, I suggest "Computer Architecture" by John L. Hennessy and David A. Patterson.
Radicode
Parent
Faster (Score:3, Insightful)
Re:Faster (Score:5, Funny)
Parent
Re:Faster (Score:4, Insightful)
like bugs in CPUs are something new....I want to know how many bugs where found in the first 20 days of the release of other intel architectures and the opteron, otherwhise I can't know if the core duo is a bad CPU compared with others or not. This article just looks like anti-intel FUD from AMD fanboys (Intel made a good CPU even with the bugs, deal with it, AMD is not going to give away free CPUs to you for being a fanboy).
And let me doubt that there's any CPU manufacturer at all that releases CPUs without any "know bug", many CPU bugs are fixed with microcode updates via new bios versions. There's a reason why both amd and Intel CPUs allow to update the microcode, they don't include features for fun.
Parent
Re:Faster (Score:5, Funny)
Yeah, I hear they're 2 to 3 times as fast now on the most important bug finding benchmarks.
Parent
Re:Faster (Score:5, Insightful)
Parent
Re:Faster (Score:5, Informative)
Given the fact that a very substantial part of the extra chip estate is being used as L1 and L2 chache, the error rate should increase less than proportionally. If you upgrade cache size from say 8 kB to 1 MB, then there is only a relative small increase in complexity of the cache controler, not of the cache itself.
Add the new chip design software and the use of hardware libraries for standard chip functionality, then the error rate should increase even slower.
Parent
Given the R&D costs... (Score:4, Interesting)
You also have to bear in mind that designs are modular and have limited connections, so N transistors is not a meaningful number - you should only be concerned with the number of modules and the number of interconnects. (eg: a 32-bit register will obviously take more transistors than an 8-bit register, but both are simply cut-and-paste copies of a 1-bit register. So long as you have the 1-bit form correct, there is no increase in complexity no matter how wide the register becomes.)
As for the interconnects - if you have N modules, you have an upper limit of !N possible interactions, if you can string any possible combination together. That's a big number, even for small values of N. But most of those don't exist. You cannot feed the output of one operation directly into the input of another. There are some special cases where there is a chain of events, but it is not something you can program with total freedom. Many operations just produce a result which is pushed back into the registers. Thus, N modules will produce only a little more than N interactions of interest. That is a much more managable number.
Then you need to consider that processors aren't "open floor plan". They are highly segmented. The term "floating point unit" literally does refer to a definable segment of the chip that is designed for floating point work. Again, from the standpoint of reliability, you can test each unit independently before doing an integrated test, so unit tests don't need to concern themselves with overall complexity or the number of other units out there.
Next up is the cost of a recall. Recalls are expensive. From a pure profit standpoint, you want to spend less on QA than you'd spend on a recall, but the less you spend on QA, the more you are likely to end up spending on that recall. The ideal is to reduce the number of potentially serious bugs to the point where any further initial clean-up will cost more than the money lost in cleaning up afterwards. Less QA than that will cost more than it saves. More QA than that will also cost more than it saves unless it expands the market (ie: the chip becomes good enough to be used in mission-critical systems such as life-support or fly-by-wire systems), but is sometimes good to do anyway for PR reasons.
Finally, not all transistors are "important". Once you know the cache algorithm works, the actual cache memory is irrelevent - memory is rarely implemented "incorrectly", it doesn't "do" anything (the active part is the algorithm), it's just heap.
With modern software verification tools, chip validation suites and the high level of understanding of microelectronics, an average of one bug for every four or five instructions is high. I would consider a chip with a third as many bugs to be only just acceptable for home use, and a thirtieth as many for operations in which any significant number of people would be put at risk. The extra cost would be minimal (compared to all the other costs) and would still be much less than the cost to Intel of the Pentium divide bug or to Transmeta of the flaws in their initial Crusoe chips.
Parent
Re:Given the R&D costs... (Score:4, Insightful)
Silicon fab facilities are extremely expensive and capital intensive, but they produce shitloads of chips. The process scales; making 1000 wafers in these fabs is as easy as making one.
Engineering analysis of complex IC designs is a perfect example of combinatorial explosion. Each bit of state in the chip doubles the state space in which bugs can exist. Yes, *most* of that state is in the cache which has regularity in its structure, but that regularity didn't happen by accident: it was *designed* that way.
You can only test to a spec, and if the spec is imperfect and has gaps, you will leave space for bugs. Given that specs are written by engineers, they cannot be nearly complete for anything other than the most trivial circuits; the infrastructure used to suppor engineering of non-trivial circuits could itself have bugs.
The part of the spec that covers the cache is simple, and can conceivably be error-free and well-tested, and perhaps with methods that are amenable to mathematical proof. But that's not where the errors crop up. The errors crop up in the hugely complex mechanisms that handle all the pipelining, branch prediction, translation to microinstructions, handling of interrupts, etc., etc., that are not highly regular and modular and are not easy to spec, and are not easy to approach with formal methods.
Parent
It's because (Score:5, Funny)
It used to be that testers only had an unstable testbed OS (designed primarily to run the same company's office suite) to use for validatation. Testers were never quite sure before where the blue screens, lockups, funny noises, and billowing smoke actually originated.
(Relax, it's just a joke).
Parent
Re:Faster (Score:5, Insightful)
Because the purpose of finding silicon bugs is almsot never to fix it. Fixing CPU bugs is often impractical. You find the flaws so you can route around them. This is the case with every consumer chip on the market, including the one you are using to read this right now.
Parent
"one of the first times"? (Score:5, Insightful)
this marks one of the first times that Intel released a processor with known bugs
No: either it is the first time or it is not. There can be only one... first time.
and some of the bugs are of higher severity then in the past
then != than
Re:"one of the first times"? (Score:5, Insightful)
No: either it is the first time or it is not. There can be only one... first time.
I disagree with the mod who marked you "Off-topic." It may look like you are just being a grammar nazi, but you raise a valid point.
Saying "this marks one of the first times that Intel released a processor with known bugs" is pretty much the same as saying, "this is not the first time that Intel has released a processor with known bugs, but I want it to sound like alarmingly bad news for Apple."
Parent
Does anyone know.... (Score:3, Interesting)
Jaysyn
Yeah some perspective would be nice... (Score:5, Insightful)
How many bugs in other Pentium chips?
What was the rate of discovery of bugs in other chips?
Keep in mind that during Intel's entire history they've released one desktop processor that had a bug sufficient to require a recall. Most of the bugs are easily worked around including that one. Hell, I've got an old P60 that I was using as a router until the last year or so and it just worked fine and it was always amusing to see Linux notice the FDIV bug on boot.
Parent
Re:Does anyone know.... (Score:5, Informative)
Google html of the pdf:
http://64.233.179.104/search?q=cache:HFDm3zBojEcJ
Amd's original (pdf!)
http://www.amd.com/us-en/assets/content_type/whit
Parent
20 days? (Score:5, Insightful)
Most of these bugs were found well before the release of Core Duo. Many of the bugs are listed as having been observed by Intel only. That means the verficiation teams did hit these issues, either with very bizarre code setup, or doing something that's probably not technically legal anyway. Odds of seeing most of it in an end-user platform are very unlikely.
Re:20 days? (Score:4, Funny)
Parent
Re:20 days? (Score:5, Informative)
http://www.amd.com/us-en/assets/content_type/whit
There's a lot more listed there than for the Core Duo so far, and quite a few marked as "Won't be Fixed" and are scary sounding. Here's an example of a rather nasty looking ordering bug that results in system hang:
Downstream non-posted requests to devices that are dependent on the completion of an upstream
non-posted request can cause a deadlock in the presence of transactions resulting in bus locks, as shown in the following two scenarios:
1. A downstream non-posted read to the LPC bus occurs while an LPC bus DMA is in progress. The legacy LPC DMA blocks downstream traffic until it completes its upstream reads.
2. A downstream non-posted read is sent to a device that must first send an upstream non-posted read before it can complete the downstream read.
In both cases, a locked transaction causes the upstream channel to be blocked, causing the deadlock condition.
Potential Effect on System
The system fails due to a bus deadlock.
Parent
AMD errata (Score:5, Informative)
Re:AMD errata (Score:3, Interesting)
Statistics (Score:3, Interesting)
First time with BUGs?!?! (Score:5, Informative)
Huh? That's clearly wrong. When Intel had its famous FDIV bug, they shipped it knowing that the problem was there (the chips were already manufactured before they noticed it in their internal design validation.) In fact I would highly doubt that any Intel chip (or AMD chip) has shipped without some known bugs in them.
Its just a question of severity. Most of these bugs tend to be highly marginal in a "real software doesn't push that hard on the CPU" sense.
Why is this an Apple issue? (Score:5, Informative)
Oh thats it! (Score:5, Funny)
Oh, thats right:
Microsoft Owns Apple.
How can we tell?
1. Apple's stock only rose 25% last week.
2. Bill Gates's birthday now a paid holiday for Apple employees.
3. Default Mac startup sound changed to "Taps."
4. Wall Street brokers have stopped using Apple stock certificates as toilet paper.
5. Apple's new slogan: "Almost as good as Windows!"
6. Apple has been bent over with its pants dropped for so long now, even a geek like Bill Gates was bound to get lucky.
7. Cute rainbow-colored apple now inhabited by cute rainbow-colored worm.
8. microsoft comes out with an operating system incorporating Mac technology
9. Phone and utilities mysteriously start working again at Apple's corporate HQ.
10. Steve Jobs seen tending bar at the Gates' private lawn party.
11. Diners in Microsoft's staff cafeteria can now enjoy their apple pie purely for its wholesome goodness and no longer as a symbolic act of global domination.
12. Unsold Newtons used as cobblestones in Gates's driveway.
13. Apple Employee of the Month gets to hunt loose change at Bill's house.
14. New Apple employee dress code includes large "Property of B. Gates" tattoo on ass.
15. Bill Gates still burned in effigy, but upper management no longer attends.
(http://www.ehumorcentral.com/Directory/Jokes/838
I like #7 and #11 myself
All modern processors have bugs on release (Score:5, Informative)
Of course, what happens is that the alpha/beta silicon ships to select customers without many errata (though internal testing often finds them too, and they ship with those). Then the manufacturer goes back, resolves a few, then the cycle repeats until everyone is happy with the bugs and it's released with a book of errata on them, and workarounds for the severe ones.
"No fix" errata are common. The most serious of those have workarounds. Fixed errata are for things where there can be no possible software workaround. But there's a large number of varying severity - from cache incoherences, lock failures (you try to lock something, and it either can't be unlocked the usual way, or it doesn't reliably indicate lock), to bus and spec violations.
Nothing new here...
Equivalent PowerPC numbers? (Score:4, Insightful)
Anyone? Bueller?
Image Mirror (Score:3, Informative)
The One I'm Waiting For (Score:4, Funny)
Cannot run Windows XP. Classification: Minor.
All CPU, controllers, etc. have errata... (Score:5, Informative)
For eample...
The MPC7410 family of chips (aka G4) from Freescale (formally part of Motorola) has 21 errata currently listed: MPC7410CE.pdf [freescale.com]
The MPC7447 family of chips (aka G4) from Freescale has 36 errata currently listed: MPC7457CE.pdf [freescale.com]
The PPC 970FX (aka G5) from IBM has 24 errata currently listed: 970fx_errata_dd3.x_v1.6.pdf [ibm.com]
AMD Opteron errata (Score:3, Informative)
"85 pages" is a misleading comment. (Score:5, Informative)
I don't dispute your comment regarding the experience of a chipset designer.
Parent
It's normal to not fix silicon bugs (Score:5, Informative)
Unless the bug is so fatal that you can't work around it, or the bug could potentially cost lives, the primary solution is to work around it. Either you write driver code to avoid the bug, or you find some other cheap solution. Sometimes, it's a simple matter of removing a feature from your marketing literature.
Intel's typical means to mask processor bugs is microcode. This hurts performance, but they can typically create a workaround that routes everything around the bug. I can't read the article (it's slashdotted), but I'm sure that by saying they won't fix some bugs, they're saying that they won't respin the silicon but rather mask the bug in some other way.
Listing the bugs (and not fixing them in this version) is an appropriate thing for Intel to do.
(I'm no Intel fanboy. I think they're bastards. But this is NOT an example of them being bastards.)
Re:It's normal to not fix silicon bugs (Score:4, Informative)
That's true. Every Intel CPU since the Pentium Pro can update its microcode. Many times, BIOS will contain microcode updates from Intel. Linux also has a microcode update driver [urbanmyth.org].
"I'm sure that by saying they won't fix some bugs, they're saying that they won't respin the silicon but rather mask the bug in some other way."
I'm not sure about that. "Will fix" seems to imply the errata could be fixed in silicon or microcode, while "Will not fix" means it won't get fixed at all.
Parent
Re:It's normal to not fix silicon bugs (Score:4, Informative)
So if you look at the list of errata, you see things like flags not getting set properly after the execution of an instruction. What could cause this? 1.) The design was logically incorrect. 2.) The design was logically correct, but the flag is never properly latched on the correct cycle for all hardware. 3.) The flag doesnt get set for slow hardware. 4.) The flag doesn't get set for hardware that has issues with supply integrity. Etc etc.
One would think that if they screwed up the implementation of a long-lived feature, it wasn't a logic error (likely to be caught by running verification) but an error caused by the analog or physical world intruding upon the digital domain. Some small amount of this may be expected-- oh crap! 1% of chips have an obscure timing issue we can't catch in test-- but if it is a true logic bug, someone screwed up.
Parent
I like the comment on bug AE9 (Score:3, Funny)
Quoth the image: Show stopper, but only observed by Intel so far. Also, any OS developer who codes like this deserves this one.
I like this comment (Score:5, Funny)
Show-stopper but only observed by Intel so far. Also, any OS developer who codes like this deserves this one.
Re:Should've gone with AMD (Score:4, Informative)
Parent
Re:Should've gone with AMD (Score:3, Insightful)
Now, this would've been interesting or informative if you would have provided a link to that PDF. Pretty please?
Re:Should've gone with AMD (Score:5, Informative)
I didn't bother to actually count the number of unfixed or no fix planned glitches / bugs in there, so I don't know if it actually validates the 80+ the grandparent claimed, but there are quite a few known bugs in A64 and its HTT bus.
In fact there are going to be any CPU released, even stuff like Power / Itanium / USpark are going to have errata like this. Microprocessors are inredibly complex equipment, and 100% stable and glitch free under all possible conditions just isn't going to happen. Who ever submitted this story is blowing this entirely out of proportion. The link is already Slashdotted so I haven't gotten a chance to read what the bugs / glitches are, but I would be good money a normal user could go through the entire life of their Core Dou Mac and never notice one. These are typically very small gliches / bugs that occur under very specific conditions, and are meant more for hardware manufacturers to be aware of than they are to warn a user there could be problems with their chips.
publishing them publicly I think is a good move on Intel's part, but they do run this risk where people don't understand that this is a completely and utterly ordinary and expected thing to happen.
Parent
Re:Should've gone with AMD (Score:4, Informative)
Parent
I think this is what he meant (Score:3, Informative)
Re:A flawed design kept alife. (Score:5, Insightful)
The problem with x86 comes from the fact that a large number of instructions interact in relatively complex ways with others. Changing a small amount of silicon can change a side-effect of an instruction, which is then a bug. An ISA such as Alpha eliminated this by keeping inter-instruction interactions to a minimum (no condition registers, etc).
Parent
Re:A flawed design kept alife. (Score:3, Insightful)
Re:A flawed design kept alife. (Score:5, Interesting)
Ah. Ok. So then -- do these "known better archtectures [sic]" have no bugs then? Significantly fewer bugs? Are the bugs less severe? And how do they compare to the Intel/AMD architectures in terms of speed? I can assure you that I can make a chip that is 100% bug free -- it's also going to run somewhere in the vicinity of the original 8008.
Frankly, I doubt you know all that much about the real ISA that Intel or AMD execute on their cores. The x86 instructions are never executed -- they're translated into an internal only ISA that doesn't look anything even vaguely like the x86 ISA.
I'm so sick and tired of all these kids out of college whining about the x86 ISA. And yeah, I was there once too. But know what? That decreipt, horrible, ghastly API has outlasted every single competitor, has been upgraded from 8-bits to 64-bits without losing backwards compatibility, and runs far, far faster than every chip that's tried to take away the title. And costs less. Intel's proven the doom 'n' gloom wrong everytime -- including with their latest transition off the Netburst architecture. AMD has as well (I give Intel props because for decades they were the only real designers for the x86 ISA; AMD is pretty much responsible for the latest incarnation as x86-64 though).
If you look at any of the modern chip architectures then none of them fall nicely and neatly into "CISC" or "RISC". The Power architecture is awfully CISC like in some ways. The x86 (the classic CISC) doesn't use a complex ISA internally, it has pipelining, branch prediction, caching, etc. -- all classic RISC subsystems that were never supposed to work on CISC. Everyone is multi-core now (to various extents).
The x86 architecture isn't going anywhere. If anything Apple's move should've reinforced this concept -- the fact of the matter is that Intel spends more in R&D than every other (general purpose) chip maker on the planet. Combined. And sells their product for less. That kind of R&D budget makes up for a lot of paper shortcomings.
Welcome to the real world.
Parent
Re:No buy (Score:3, Informative)
Re:No buy (Score:5, Informative)
The documented and known errata are not what you should be concerned with. It's the unknown ones that freeze your computer or cause all robots to attack their masters.
If someone's complaining about this, they should just turn off their computers, because as we ALL know, every operating system (the OS is what runs on chips that have the errata) also are shipped with hundreds, if not thousands, of known bugs. You're not going to find a perfect chip in the real world. How many errata did the G4/G5 have? By comparison the IBM PowerPC 970FX has 24 errata, none of which is planned for a fix. When you consider the 970FX is a fairly mature chip, 34 errata on a new chip is hardly news worthy. As transistors get more and more compact and miniaturized, I'm sure we're bound to see more.
Parent
Re:Safety critical software developers beware.... (Score:4, Insightful)
Parent