Slashdot Mirror
34 Design Flaws in 20 Days of Intel Core Duo
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."
I just think it means that Intel is being more honest about the problems, rather then hiding them til others find them.
Maybe they're just getting faster/better at finding bugs?
Bradley Holt
You do realize that there is an 85 page PDF of errors in the AMD64, right?
Wow, that was out of nowhere. Do you think that there are no flaws in AMD processors?
Also, where the hell did DMR come in? You just like throwing that in to boast AMD?
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
I want to drag this out as long as possible. Bring me my protractor.
How many "bugs" are in Athlons?/Duron/Semprons?
Jaysyn
There is a war going on for your mind.
It's a little disohnest to use the phrasing "Core Duo chip has 34 known issues found in the 20 days since the launch of the iMac Core Duo."
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.
Revision Guide for AMD AthlonTM 64 and AMD OpteronTM Processors. Just for balance. (only two of them are really interesting, #113 is one of them IIRC)
Another thing here that people don't seem to get, is that just because there have been 1.5 'found' a day (I would bet most were known before general release), that says nothing about the total number of bugs. For all we know, there could be only 40 total, just most of them were found quickly.
If the flaws are more serious then in the past, than I hope they'll get right on to fixing them rather then making new ones...
*arrrrrgh* My brain hurts from injecting the spelling errors.
I don't know the meaning of the word 'don't' - J
Can someone post an analysis of the bugs and how they would affect software, especially reliability of the operating system. Hardware has always had bugs and errata and sometimes even gets fixed (FDIV bug comes to mind). It is the criticality of the bugs and what the plan to address them include (tool changes).
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.
Apple is not the only manufacturer using the Core Duo chip.
Strange women lying in ponds distributing swords is no basis for a system of government.
Why does Apple want to use an intel chip?
... uh, wait a minute ...
. html)
:-)
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
This has been another valuable and informative opinion from:
Catahoula!
It's called "errata", and it's common for most processors to be released with pages and pages and pages of errata.
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...
Now, this would've been interesting or informative if you would have provided a link to that PDF. Pretty please?
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
I mean, there is MS which admits its s/w has bugs after every cat and dog knows about it, and here is Intel, which talks about its bug even before the product is released!
This news would be a lot more interesting if I knew the size of the errata list for the G4 or the G5. I think it unlikely that there are zero unfixed bugs.
Anyone? Bueller?
Considering that there are several other PC vendors who offer Core Duo based machines, I find it odd that this particular post focusses on Apple and the iMac.
...Pobody's nerfect.
Nothing sucks like a Vax, nothing blows like a PowerMac G4
34 known issues found in the 20 days since the launch of the iMac Dore Duo. (you can read the list) with only plans to fix one of them.
34 bugs is nothing when you can say to all your friends how you have the latest 'Dore Duo' processor.
Besides, other large computer companies have bugs in their software and they take their sweet old time to fix them.
If they can do it, why can't anyone else?
He who knows best knows how little he knows. - Thomas Jefferson
geeks.com has pumped up these problems by doing their own analysis, and claiming 'show stopper' on many of them, yet there are already machines in the wild that seem to have no problem with many of them. Like them saying that machines wouldn't be able to wake from sleep because of one of them. Their analysis is a lot of FUD.
this just adds more fuel to the fire for me about not wanting to make the switch just yet. Sure be an early adopter the voices say, I would rather wait. I hope a second gen POWERBOOK!!!! (screw the MacBook Pro name) gets released later this year.
It's going pretty slow, here's a mirror I setup to the image with list on it: http://www.xmilk.com/coreduo.gif
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
Cannot run Windows XP. Classification: Minor.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Apple didn't go with AMD because they (AMD) are going in a different direction then what Apple is looking for. Apple wants less power consumption to drive the new Powerbooks (i refuse to call it by any other name), and to make small for computers like the Mac Mini and iMac. AMD is not making low power processors. So its not as simple as "Apple should have gone with AMD." I feel they made the right choice for what they think the needs of the company are.
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).
I am TheRaven on Soylent News
So not only how many bugs in Athlon, etc, but also...
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.
This sig has been temporarily disconnected or is no longer in service
You, of course, have a reference (link) for this.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
This remembers me the centrino bug, with no fix intended.3 0220907.pdf but now I can only find http://www.intel.com/design/mobile/specupdt/302209 .htm which leads to a password protected PDF
PAE support is broken on the Dothan (most Centrino) CPU and no fix nor workaround is planned by Intel.
Due to this, kernel with PAE enabled (needed at least for NX support) won't boot on Dothan...
PDF used to be on http://download.intel.com/design/mobile/SPECUPDT/
Not sure I understand the point of this new article... all chips have errata. This is like reporting that the sun set again or that slashdotters have no love life.
For eample...
The MPC7410 family of chips (aka G4) from Freescale (formally part of Motorola) has 21 errata currently listed: MPC7410CE.pdf
The MPC7447 family of chips (aka G4) from Freescale has 36 errata currently listed: MPC7457CE.pdf
The PPC 970FX (aka G5) from IBM has 24 errata currently listed: 970fx_errata_dd3.x_v1.6.pdf
The errata for the AMD Opteron is 85 pages long . I once spoke with a chipset designer and he told me that the Opteron errata was especially long with some convoluted workarounds, compared to other CPUs he's worked with.
As an ASIC designer, I have produced my fair share of silicon bugs. Chips are expensive to produce, making bugs expensive to fix. As a result, chip designers (even ones with deep pockets like Intel) do not look at bugs as something to FIX, but rather as something to MASK. I don't mean to hide it from people (although that does happen), but to make it not a bug by working around it.
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.)
You do realize that there is an 85 page PDF of errors in the AMD64, right?
you forgot the link to that. (I shamelessly copied it from AC's post, why he posted it with score:0 is mystery to me - no one would notice it. He indicated that #113 worth looking at).
#
#\ @ ? Colonize Mars
#
Could that be the reason why Apple didn't allow their new MacBooks to hibernate at Macworld?
:)
Imagine the possibilities
http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf
And as an aside, it took two seconds (actually .08) seconds to look up on Google. Maybe try that next time.
How pathetic are you that you follow me from topic to topic and waste all your mod points at once modding me down?
we will miss the AlteVec Velocity Engine and 64-bit full RISC processing, no doubts. Lets hope Intel designs something as useful as AlteVec developers can take advantage of, and gets Apple a 64-bit chip soon.
The Admin and the Engineer
Being in the Aerospace/Defense industry, this is disconcerning, especially for those of us that deal with the FAA and the imfamous DO-178B. Higher demanding systems are forcing us to use more powerful processors and if they are plagued with "known issues" it may be a problem with getting through a certification by some governing agency. Especially now that DO-254 has reared its ugly head... Has Intel gone the way of Microsoft? Delivering early to gain market even though the product has sever quality issues and then take the "well, it's not a critical secutriy flaw?".
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.
It looks like AMD keeps errata listings for their chips in the "AMD Dev Central Vault" which requires a registered login... so it may not be possible to do a direct link (at least I couldn't find them after searching). I assure you AMD chips have errata to varying degrees and in generally the same numbers as just about ever other chip vender (see my other post for an example listing).
http://developer.amd.com/documentation.aspx
Here is AMD's errata: http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf.
Cheers,
Saad Mahamood.
http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf
Coral Cache of the image
Quoth the image: Show stopper, but only observed by Intel so far. Also, any OS developer who codes like this deserves this one.
I am NaN
I think we donated to charity while it was still usable with recent software. We actually got the 'new' chip sent to us tho, that was cool. First time I had pulled a chip more complex than a DIP!
Blar.
Next week they'll take on the difficult subject of "changelogs" and the mysterious "READMEs" you see everywhere.
Ah I see the just don't have the word errata in their document name or on the their website... it is down in the revision documentation.
And you think that the A64, and P4 are clean and squaeky?
I'm not GP, but here you are: Revision Guide for AMD Athlon(TM) 64 and AMD Opteron(TM) Processors, 85 pages PDF, the "product errata" starts page 13 and the product errata cross-reference table itself is 4 pages long, the following pages being the descriptions of the various errors.
if some one had the time to create one (and balls to go against the big M$) there would be a some odd 1000 page PDF of windows Errors/bugs/flaws/backdoors/un pached holes.... and so on
(yes i know i suck at spelling fell free to correct my grammar and/or spellin i dont care, im still not going to change
It's not a bug ... it's a feature.
... for the first time, they're releasing the chip for a stable OS first.
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).
sigs, as if you care.
No, that's what you get when you build something really complicated. The clever bit is that they still work despite the errors.
Bad analogies are like waxing a monkey with a rainbow.
All chips have errata, and custmarily are well documented and are published on the vendor's web site. BTW, errata can be something as simple as a correction to the datasheet. Most are usually minor and are dealt with by the compiler. For example, if there's an error with calculations dealing with a certain registry and decimal values, the compiler would just not use that registry for the calculations.
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.
Mac Powerbooks and G5s are WIDELY used as THE copmuter for editing film on. The new MacBook does not properly run Final Cut Pro 4, one of the biggest names in editing software. BIG mistake apple, big mistake.
AE 16:
Show-stopper but only observed by Intel so far. Also, any OS developer who codes like this deserves this one.
People were all excited by the idea thay because the CoreDuo was socketed it sould be upgraded. Looks like it may have been so that they could be replaced easily if there were huge flaws discovered after shipping the units.
You mean like SSE3, which the Core Duo has?
English is easier said than done.
Maybe next time it will all be fixed......
I'm sorry if this sounds combative, but clearly you're more in love with PowerPC and IBM than IBM is in love with you.
I don't really enjoy being on Steve Job's cheerleading squad here. The transition has a lot of annoyances, not the least of which is the fact that Adobe isn't going to go Universal until late 2006 or early 07. But, judging by the number of people I know with PowerBooks, and the number of people I heard screaming, praying, and crying in their sleep for G5 laptops, if there had been any plans for a low-power, low-heat G5, we would've seen it already.
While software bugs have (almost) always a solution, for the hardware ones sometimes the solution is so far (and hard) to make the hardware itself unreliable when not useless.
I'd suggest Intel to be made liable for those bugs, provided that after these news it will be able to sell those chips!
Intel should reclaim the chips e substitute them with fixed ones. As it happens for cars.
And it would be nice to see the bug lists for AMD and PPC chips as well!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
"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) "
Is it just me, or do the statements "with only plans to fix one of them" and "does not plan to fix a single one" conflict with one another?
"We are all geniuses when we dream"
- E.M. Cioran
In case you aren't following the thread, this post has the link:c id=14549163
http://apple.slashdot.org/comments.pl?sid=174966&
Computers allow humans to make mistakes at the fastest speeds known, with the possible exception of tequila and handguns
It's not surprised that their are errors and I'm glad that Intel isn't hiding from them. It does open the question on whether Apple is happy with the CPU itself because of the high standard they have set.
[%] Cingular Ringtones
Yeah, I know - there really isn't that much difference between a 1.8Ghz Core Duo and the 1.8Ghz dual-core G5 in the current Powerbooks.
Er. Wait a minute. There's no such G5 in a Powerbook? The best we had a single core 1.5Ghz G4? Oh - well perhaps there is a substantive difference in chips, after all.
concrete5: a cms made for marketing, but strong enough for geeks.
the new Intel Macs are only 1/4 faster (rather then 2-4 times faster as Jobs claimed)
If you bothered to read the keynote speech, you'd know he said no such thing. He said the processors were 2-4 times faster and then specifically qualified it by saying running applications would not be 2-4 times faster, since so many other parts of the machine were the bottlenecks. You're linking to application tests, the part he actually told you would not run 2-4 times faster.
Slightly more ontopic - I've been reading that the mere presence of the fat binaried itunes on a powerpc mac can cause the disk utility not to run - stripping intel code from the binary fixes the problem.
How is that on topic? This is an article about bugs in the intel processors. How does some obscure possible bug that only affects PPC systems relevant?
Let's not just moderate comments.
I want to be able to moderate articles for depth, due diligence, and bias.
This one's going to sit at top level for quite some time, trolling in everyone until they read the comments and discover they shouldn't have bothered.
No, he said "something as good as Altivec."
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Processor bugs have been around as long as processors. For example, I remember on the Z80, Zilog didn't particularly confess to the bugs - they just didn't list the affected instructions in the documentation. By looking at the byte codes, programmers were able to spot where an instruction be. Upon trying it - usually, you'd find that it largely did what it should but with a few unexpected behaviours. Once understood - you could pretty happily deploy them, with the caveat that Zilog might change the processor and render them unuseable. If memory serves me right, 'unofficial' instructions constituted 5-10% of the instruction set.
In he case of bugs in modern processors - as long as they are published, fully understood, and don't affect absolutely critical functions - compiler manufacturers, and the few programmers who still code in assembly language, can code around them quite happily.
Far more of a problem are unreported bugs (like the notorious floating point issues in previous processors) and unreliable processors (like ones which overheat easily and crash - trashing your work).
Is the gp off topic? Not really. It needs to be pointed out that the submitter is purposefully blowing common knowlege (bugs exist) out of proportion ("one of the first times").
What is off topic (but painfully obvious) is that the submitter has very little grasp of grammar. This is important. I am sick of slashdotters complaining that the nontechnical press gets tech facts wrong all the time but continue to mangle grammar consistently. It goes both ways. And it wouldn't be so bad if it was just commenters, but it is the submitters. How hard can it be to reread something before submitting it? How hard can it be for the editors to check it? Wait, don't answer that. They already can't find dupes...
I would post this under my username, but I already modded the gp up.
Did we forget about the pentium bug a while back? Um, Divide by zero errors, etc that many operating systems had to make work arounds for?
I think the term you seek is REGISTER. The registry is something (ahem) different.
New MacBook Pro, 4x more bugs !
Apple is the only company with any Core Duo machines who is able to get any buzz around there product, for a few reasons.
1. Apple is now on intel, so that's big news.
2. The press likes apple right now.
3. Apple knows how to market to consumers. "iMac" gains more traction that the new "HP Pavilion dv1000." The "iMac" is a product even my parents can name. The HP Pavilion dv1000 is just another part number nobody ever remembers.
-Pete
Soccer Goal Plans
Description of AE4 and AE11 are the same except that AE11 doesn't have the parenthetical explaination of the REP MOVS instruction. AE4 is called a show stopper, AE11 characterizes it as a mere performance issue.
i think the understanding is that Intel was way ahead in processors for portables, or small devices (Mac Mini etc). either they are today, or their roadmap looks better.
if it was about the all out power of Intel vs AMD for desktop towers they would probably still be using IBM chips. there were issues with ramp up speeds of the G5 chips, but the G5 tower is a FAST machine. the problem was cramming that power (read: heat, power draw) into a laptop.
Hmmmm....
What wast the (newsworthy or not) bug per CPU per release count BEFORE switching to Intel? What happened to all that new-fangled "chip simulation" stuff? Seems if this erratta is not just typos and such, then the SIMulation needs some STIMulation to be more useful.
I wonder if AppTel did a "test design" before the Apple side of the house went to market. As for "finding the bugs faster", I am wondering if Apple found them and told Intel, "fixem or we go back to IBM, even if IBM charges more money to come back-but you can be sure we won't pay YOU over flaws we specced to be avoided...", assuming Apple could foresee and document what to avoid.
As for Intel being "more honest", heck, I am willing to assume Apple has a better branding position than Intel, and Apple is not going to stand for Intel using it's mammoth inventory and factory count to roll over people. Any heavy computer user-- particularly Mac users who make money by USING their computers in small businesses-- will not tolerate Intel chips if things don't turn around.
And, finally, I imagine Jobs will do a war-dance job in Intel if they think ONE bug fix is all that's required or if they think they can get away with fixing only ONE bug. But, if they are firm on fixing only ONE "BUG", then maybe they have refunds, refurbs, exchanges, chip-swaps... and/or a new chip in the pipeline...
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
I've heard rumors that some small PC manufacturers, such as Dell and Gateway are selling computers using this cpu.
Just leave it in "BETA" google does a good job at that.
Well, yes, it is basically the API that stayed the same. But there is still a major difference to software APIs. It's much more costly to make that translations. In C++ you can often make wrapper classes, and a good compiler compiles them away and you basically barely see any difference at runtime. On a chip every translation of each instruction has to be done each time. And just the logic to impement that takes a big amount of die space, and is of course a source of heat and errors too. And all this additionally to the instruction side effect problems you mentioned before.
If you have the source, migrating to another processor is not that much work (except on close to hardware operating system stuff, but even that is a very small amoutn of each modern OS). And more importantly, it is work that is only done once, and not a billion times each second for each instruction and burning energy.
If you don't have the source, and you really need to run windows 3.0. Well, then do it on a i486, that's more than enough for that.
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
One notable bug turned into a features was the A20 Address Line thing.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
This is coming from the company that gave IDE a fighting chance against SCSI when it introduced IDE busmastering on it's 430 series chipset. This is the same company that made the 440BX chipset which was possibly one of the most popular chipsets for it's time. It featured new advanced core logic. Most boards with that chipset would let you use Celerons, Pentium II's and Pentium III's. Of course BIOS updates allowed more multiplexors in many cases. Intel was good about putting out driver updates on alot of its products. I admit that the Intel 536ep soft modem initially had some poor connectivity rates at times. But after a few driver updates, that was fixed. Intel also made the Application Accelerator which optimized disk controller performance. Intel was also responsible for Plug and Play and AGP. That's not say that those technologies weren't without their problems. And I'm certainly not saying that Intel was perfect, either. I just think it's ashame that they're not taking more pride in their work.
He just said he didn't. Do you have reading comprehension problems?
For AE12, normally if you're doing something where inexact representation is unacceptable, you'll need to use a bignumber library or similar anyway (depending on the application, scaled ints may be preferred). It IS a bug, but there IS a (somewhat painful) software workaround.
In general, it looks like their color coding has little to do with the actual seriousness of the flaw. AE20 for example, Just how likely is it that you'll reset just one of the processors and not have the other in a safe state? Perhaps they should have reserved red for non-existant workarounds, yellow for really painful workarounds, and green for not so painful ones?
For the most part, these don't look any worse than the ones in other processors that are routinely worked around in the OS. Have a look at enough Linux kernel code and you'll see what I mean.
It would be reallky nice if all errata were fixed, but it never happens and this one is no worse than the others.
Your comment is misleading. The document lists only 61 errata and contains their respective details. The initial table of errata -- table 5 -- is only four pages long (begins 13 and ends 16) and is most likely to group the problems by the wafer families; the next two pages reiterate the errata for each given brand name of AMD K7/K8 chip; all but one of the remaining pages detail the errata and their suggested workarounds/fixes. The last page is a list of extra resources.
I don't dispute your comment regarding the experience of a chipset designer.
>> Slightly more ontopic - I've been reading that the mere presence of the fat binaried itunes on a powerpc mac can cause the disk utility not to run - stripping intel code from the binary fixes the problem.
> How is that on topic? This is an article about bugs in the intel processors. How does some obscure possible bug that only affects PPC systems relevant?
Amen brother. I love how PPC fanboys use this fact to bash the Intel transition, while it's a bug in the *PPC* Disk Utility in the first place.
Mystery solved!
My uncle once told me to never get a R1 motherboard for this very reason. This is all a new technology implementation here. There are going to be problems. Part of getting R1 of any advanced technology is going to be probably dealing with bugs.
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
I have a macbook in order. I keep wavering on canceling the order (it doesn't ship until Feb. 15, if that's to even be beleived). On one hand, I really could use a laptop, and while I run linux on my desktop, would prefer OS X on a laptop. While not necessary, I like the idea that windows and linux will be easily available if I need it.
I also wonder if AE30 relates to the reports that the laptops crashed when put into hibernation.
I might be wrong, but I will have to trust that Apple will be very careful in putting out a bad product. The Macbook is their new flagship for laptops. If it sucks too badly, the nice shiney image Apple has managed to construct for itself will be somewhat tarnished. Not having dealt with Apple before, have there been other instances of them putting out a 'broken' product (i.e. am I stupid in beleiving everything will be okay)?
I have to say that only 32 seems pretty impressive. If you look at software, Windows has had innumerable bugs and continues to find and fix them years in. Although I'm not sure it's a direct comparison between the number of transistors and the number of lines of code... Fixing hardware flaws means re-printing chips, which means re-engineering a number of steps in the chip making process (Changing masks), as well as re-calculating em-fields and heat dispersal across a chip to insure it won't melt or short circuit. It's not like they can just white-out the mistakes.
I wouldn't consider the mad hatter mad. Just reality impaired. He sure can make a mean cup of tea.
This has everything to do with Intel, and absolutely NOTHING to do with Apple. Apple is not the only company using the Core Duo. There's no reason to imply that Apple is at fault or this problem relates to them in any way that it doesn't also relate to any other manufacturer using the Core Duo.
Just my 2
To be fair the 85 page PDF is the complete Errata documentation. The list of bugs is only 3-4 pages long (approx 60 items). This also covers the entire Opteron and Athlon 64 line and in many cases the bugs only apply to a subset of those dies.
Just clarifying.
nos laetus epulor qui would domito nos
Every chip has an errata sheet. The number of elements on the errata sheet is proportional to the complexity of the chip in question and the age of the process it is fabricated with. The Core Duo by Intel has complexity comparable to 2 PowerPC 970FX Series which its replacing and is fabricated using 65 nm technology. The PowerPC 970FX is fabricated using a 90 nm process. It has 24 items on its errata sheet (http://www-306.ibm.com/chips/techlib/techlib.nsf/ techdocs/79B6E24422AA101287256E93006C957E/$file/97 0fx_errata_dd3.x_v1.6.pdf). Therefore its expected that a chip fabricated on a substrate whose minimum feature sizes are half those of the other chip and whose complexity is double the other chip would have 4x the errata items of the other chip.
Sir, what are you doing? This is Slashdot, where everybody for some reason has a hard-on for AMD and ignores their flaws while pointing out Intel's to further their fanboy agendas. For crying out loud, we almost had a moment of calm, rational reasoning there. It's almost as if you're suggesting that the submitter is blowing things out of proportion, and that is IMPOSSIBLE HERE! Our system is fool-proof. Good day.
"Sufferin' succotash."
You do realize that most of the bugs in hardware can be worked around in software, right? That its cheaper/faster for Apple to just code "work-arounds" and run their unit tests then it to go back and re-fab some 65nm chips and hope that one of those bug fixes didn't break something else down the line...
No, as a matter of fact he wrote "AlteVec Velocity Engine". Which might give you some idea on how much he will actually miss it.
Does anyone know how I can mod the article down as "stupid"?
Well, that's what you get when you stick to crufted designs and try to keep them at all costs although there are known better archtectures. It's just like code: it gets unmaintainable over time.
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.
"Strange women lying in ponds distributing swords is no basis for a system of government." Gee i don't know, the above produce an enduring myth of a hopeful return to righteousness, a transcendent goal (the Grail Quest) and some damn fine stories. In contrast we have George... lets see, what would a similar, possible legacy for the next millenium and a half look like... ah yes, it would look something like a bad prequel to the Lord of the Rings (completely unauthorized of course) "Mordor the early years" or some such. Mod me utterly off topic roast me over cyber coals if you must but i could not let this one pass...
But that's unpossible! Apple would never ship a computer using a chip with known problems. I don't believe those papers. Some anti-mac stupid wintel weanie must have hacked those websites and posted those fake files.
</stupidity>
It is a sad day when pointless powerpc mac fanboyism is posted as news that matters. I find it odd how many Mac fans are hopeing that switch to Intel will fail. It is a small but vocal minority. They have been looking for every reason to hate the new x86 Macs, from technical limitations, to grand conspiracies. All the while they dream of Cell based Macs that never would have been made.
Apple switched to Intel because Apple needed to work with a manufacturer who is dedicated to making chips for personal computers. Neither IBM (servers) nor Freescale (embeded) has that dedication.
"Welcome to the real world."
In the real world, it took a team of about 100 to design the MIPS R10000. In the same real world, Intel's design team sizes exceed 1000 people. Which do you think is likely to have less bugs?
Intel has had errata since Appendix H was published in 1993 during FDIV.
So everyone wants to "swift-boat" Intel.
Here's a dirty little secret:
AMD DOES NOT POST ERRATA.
I would expect more from you Taco, you've been doing this so long.
https://www.accountkiller.com/removal-requested
Therefore its expected that a chip fabricated on a substrate whose minimum feature sizes are half those of the other chip and whose complexity is double the other chip would have 4x the errata items of the other chip.
Complexity of the CPU contributes some to the amount of bugs - more project work = more bugs, though only in cases of introducing new algorithms, not in case of adding "more of the same" - dual core CPU is NOT supposed to have twice as many bugs as single-core counterpart, because the two cores are identical, contain the same flaws as the single core, and new ones are introduced only by the extra glue logic that makes it "dual". Twice the complexity usually means twice the number of gates, not twice the difficulty of design - stuff like cache memory swallows a major part of available space but 64KB of cache is associated with the same number of bugs as 4MB of it. So not x2 by complexity. At most x1.5 or so.
And thet errors are not manufacturing flaws, they are design flaws / software (VHDL) bugs. If I write a program twice as long as original and save it to a harddrive of double the capacity, am I expected to have four times as many bugs? The new technology has its own share of problems but they are to be caught before releasing the chip from the factory, and chip that has a technology-related fault is just faulty and should be replaced. It has nothing to do with what appears in errata.
So - the new CPU can have more bugs than the old one. But not four times as many!
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Cared to check yet which ones are even reappearing from the list for Dothan/Banias? That would make the number of 34 in so-and-so many days even more pointless.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And how many people do you think it would take to make an effective compiler for the MIPS R10000? Give ya a hint, there still hasn't been one made. Apple code still required tons of hand-tweaking to run acceptably. On x86, the hard work is on the processor. On RISC, it's in the compiler. And since languages and so on change so much faster than a CPU instruction set, I'd much rather have it the way x86 does it than the way a RISC chip does it. It took fewer people to make the chip because it's simpler and stupider and assumes smart software. And we all know how well any software is made.
My blog. Good stuff (when I remember to update it). Read it.
It's never been about the general public, Apple's always been special for its owners.
And now it's found its true niche: as a betatesting bed for PC processors. Thanks, Apple.
- A PC owner
PS: Pitty for the Centrino II laptops though
PS2: And if gotta be serious, well all chips have flaws, so wtf. It'll work just fine.
Thank you for your well reasoned response.
With regard to your 'dual core' argument. It is true that each core is the same, but the memory controller will be more complex (among other things) so your still assuming more complexity.
With regard to your 'algorithmic' argument. Your assertion that bugs only come from the algorithms expressed in hardware is wrong. At 65 nm tunneling electrons and short gate effects can cause otherwise functional blocks of logic to malfunction. Indeed, a chip may have many such malfunctions caused by these gate level effects. An errata list will contain issues whose base cause is the silicon not the designer.
Of course the 4x metric is fairly fantastic and a gross oversimplification, but it is a metric. In my post I should have said something to the effect that 4x would be a good upper bound on the number of bugs a chip would have with twice the complexity and half the feature sizes of another chip. If I saw a chip with 10x the number of errata of under the same circumstances, then I would be surprised.
Well this goes along with the new Apple announcement for a compatibility layer that recreates a genuine Mac OS 9 experience on an Intel-powered Mac. ...
I'll shut up now.
That's exactly my point. All the effort that has to put into it just to make it still work at all. And it's not just on the R&D of intel that all this effort has to be taken. This register starved PU and this horrible MMU. It funny how many design papers you read of people who really wanted to be inventive and bring up some clean designs. And in the introduction of those papers it's almost always a good bet to to expect finding some sententence in the spirit of "Well, we'd just rather do it this and this way, to have a clean and efficient flexible design, but due to the xxx restriction of the x86 architecture, whhich is the dominant on the market, we have to do the following suboptimal workarounds:" and then comes a list. Those kind of sentences I have read in Java whitepapers (x46 is the very reason it's a stack engine), in the L4 kernel documents, in quite a few comments in compilers and the list goes on.
Up to about 15 years ago x86 was ok. Up to about 10 years ago it was bearable. Everr since then it's a mere roadblock for software and hardware development. One that had to be steered around with much efford on a daily basis. Mos people just don't notice it anymore, because they got used to it. Intel builds Ford Ts. The have a big advantage in manufactoring methods and and in economy of scale. And it sure has it's merits. Bet even the Ford T wasn't built for 20 years. If Ford did what Intel does we'd still have to start the car at the front with a lever. And actually we do. We start in real mode.
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
This story has little to do with Apple or Intel. Apple isn't the only one using Intel's chips, and Intel's chips aren't the only ones with bugs. There is no source given for their "Potentially Catastrophic!" claims about some of the bugs, and no similar counts of errata in other chips.
A story would be something like "Flaw in Intel chips Requires Recall" -- but that's not what's going on here.
-1, plays into fanboyism.
AMD has always had more bugs, and some for more serious then the intel one that sparked enough consumer backlash (out of panic) to have a recall.
I have seen drastically more 'glithes' with AMD the Intel.
For the record, I only care about performance, not name.
AMD may hit higher clock rate, but that does me no good when I can't rely on the chip.
The Kruger Dunning explains most post on
... and I just ordered a Duo laptop about 2 hours ago from here
(I know these bugs probably won't affect my system all that much, but its just funny spending $3k on a laptop, only to read about "issues" a couple of hours later).
You create your own reality - Leave mine to me.
In other news, writing inflammatory FUD about Intel and Apple is a great way to drive traffic to your site. Bonus points if you can lace your content with memorable phrases like "Potentially Catastrophic!".
Don't become a regular here -- you will become retarded.
Tequila and railguns.
Handguns are, like, so yesterday.
I've fallen off your lawn, and I can't get up.
are pouty about not being select.
Of course they don't bother to relize, historically, AMD chip have had many more serious 'flaws'.
The Kruger Dunning explains most post on
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
Maybe if these corporations worried more about ironing out bugs instead of creating the fastest processor on the market, then we'd have more reliable computers.
Is There A Cockroach In Your Apple? ;)
Different insects for different level of "severity" of "bugs".
A real bad bug = Scorpion.
A simple not too bad "bug" = Butterfly
A dirty "bug" = Cockroach.
And
And
And
Why is there a picture an old iMac G4 with an intel logo over it in this article?
Mac toys and accessories blog
With regard to your 'dual core' argument. It is true that each core is the same, but the memory controller will be more complex (among other things) so your still assuming more complexity.
;)
Yes, that's why the "1.5". It is there, it is complex, but it's not nearly as complex as each of the cores. Of course dual core will have more bugs than single core, but not twice as much.
At 65 nm tunneling electrons and short gate effects can cause otherwise functional blocks of logic to malfunction
Still they are a probability-based stuff that should be catchable by tests. In modern technology a big percent (30-90%, varies over time and technology) of manufactured chips is faulty and discarded because they don't pass the tests. Of course some faults will slip through the tests, but I honestly doubt they would make it into erratas, because they are "instance" bugs, characteristic to given single chip (not series, not revision, I mean physical device - two PCs with two identical CPUs may behave differently because one of them has given bug and the other doesn't.) They result from impurities of material, glitches and wear of equipment, just plain dumb random distribution of atoms (luck) etc, but they are usually unique - a chip with given bug is manufactured once. The way of dealing with them if they are located is extremally simple: the bug test is added to the suite of tests, and any CPU failing the test is discarded, together with all the other faulty ones - so no reason for "won't fix" flag in errata!
Unless of course given condition occurs in a bigger percent of the CPUs (like, 10%?) and Intel decides it's cheaper to keep selling broken chips and note that "it happens" than to discard them and sell only flawless units.
4x would be a good upper bound on the number of bugs a chip would have with twice the complexity and half the feature sizes of another chip.
In one hand - the theoretical minimal radius of turn of a car is square root of sum of the distance between the axis and half the width of an axis, squared. (real definition from some book). Of course all cars can turn front wheels 90 degrees and pivot on one back wheel in place, yeah. Strongly theoretical boundary
In the other hand: Not really. Halving feature sizes doesn't double the amount of problems - they are already working on threshold of failure. It's more like halving the thickness of beams of a bridge, corresponding to probability the bridge collapses. A chip of given design, in given technology, with paths half as thick, will not have twice the bugs. It will be completely FUBAR. That's why the whole "new technology" together with algorithms of safe laying tracks at reliable non-tunnelling distances, methodology of finding faults etc - it may be less reliable, or more reliable - but not related in terms of reliablity to the old one. It just carries its own, completely new range of problems - and errors. Not related to core design too.
So why I still say 4x is bullshit?
Getting good Bohr Bugs you can put in errata from the technology problems is very unlikely. If a problem related to technology persists to happen in one place, it will appear just the same in a thousand other places, because designs get recycled and there's really little unique stuff that could develop unique problems. A 32-bit register in silicon is just the same 32-bit register thorough the whole chip, no matter what it does, and if a fault sets bit 18 of one of the 32-bit registers at random in given core, it will tend to do so thorough all the 32-bit registers in the chip - not necessarily the same instance, but the same series. If one byte of cache fails, any byte can fail just the same way. Not an acceptable bug, must be fixed. So either the bug is too common to be ignored (multiple locations in the same CPU) or too uncommon to be noticed (obscure unique feature, obscure conditions and one in a million produced chips has it.)
To be "erratable" the technology-related bug must happen in unique place so
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
its sad to watch us as consumers of this technology, without access to the xnu or gcc source for Intel arch, we are unable to work around any of the flaws mentioned in this article and once again hope Apple is persistant in their efforts to stabilize their code. Lets recap, Intel is pointing out thirty-something hardcoded flaws which they are unwilling to address, apple has forked their Darwin source code to hide all intel source from the public and only share a dead architecture to _innovate_ on, and we are eating it up like the kids in willy wonka's coco factory all fixated on some new secret candy with drool dripping down our shirts in diabetic coma... ...pretty sad if you ask me, Apple's advertisements keep pushing "We have freed the intel chip" when in reality the intel chip will never be open again. What does slapping DRM/TPM/EFI on a chip do to free it exactly?
I will continue running Linux on my open intel chip as it is free to be added to or subtracted from as needed by me, not Steve, Bill, or the lawyers they control.
I agree. Now that consumers can make a direct comparision of a Dell with a Mac it is going to be harder for Apple to set Macs apart. Judgeing by the number of people buying bottom end Dells, trying to market "hardware quality" is not going to gain market share. Apple is going to have to sell Macs on MacOS alone.
I think the home market is more then ready for MacOS. People of fed up with Windows and its problems. However home users are paying at most $500 for a disposable computer with monitor, keyboard, mouse, speakers, and maybe even a printer. Good luck trying to convince them to pay only $150 for a Mac Mini with the same junk. Worst there is no $650 Mac Mini bundle at the Apple store.
I don't own a mac but I have always liked them. I will be in the market for a laptop next year. I hope there will be a 12" x86 powerbook then.
My original post postulated that the alarmist nature of the original post was out-of-place. I attempted to back this up with an argument that compared 2 chips and tried to demonstrate that the 30 or so errata in the Intel Duo was a reasonable figure.
With that out of the way.
I feel my metric is a fair, albeit rough way of measuring how many errata a chip should have as compared with its peers. I understand your argument that CPUs are complex but you are, in effect copying a design and that, in your opinion gate level effects would manifest themselves as reductions in yields, not errata items. I disagree that a memory controller is less complex than a CPU and I also disagree that gate level effects are not the root causes of some errata.
Back to the issue at hand, do you think that 30 errata are excessive in this case, why do you feel that way and what metric would you use to measure errata thersholds?
As a rule of thumb, the amount of cycles of testing a chip goes through in the first minute of being powered on is equal to ALL testing cycles that happened before manufacturing said chip. Umpteen million transistor chips can be software simulated on the order of tens or hundreds of operations per second. These same chips - once manufactured - run at billions of operations per second (that's what gigahertz really means after all...). At some point, you have to fab the damn thing to find more bugs.
Well, possibly it was too alarmist. As for me, 34 flaws are few. I'd expect more like 80-200. In two years. Even 50 flaws on the day of release, as results of known bugs found thorough internal tests, "we found it in the ready product. Correcting this would be too expensive, they aren't important enough." - fine. But 34 flaws in 20 days since release, many reported by outside entities - that's some outrage. Errors are unavoidable. You will make them, no matter what. You can only do your best to detect and fix them. Intel failed at the "error detection" part all the way, and they refuse to do the fixing part. And with 30 serious flaws in two weeks, what's the chance that one REALLY critical will be found in the next months? The problem isn't the "34" but the "20".
There are bugs and bugs. If you browse bugzilla.mozilla.org, you'll find minor bugs untouched for years. Nobody bothers, nobody worries. They are mapped. they aren't in the way, they aren't dangerous. Hundreds of them. But if somebody finds a security-related bug in "stable" version, what an outrage!
Would you rather fly a plane running software that was very thoroughly tested but not fixed afterwards, having the bugreport list in hand, knowing well which option is broken, which ones to avoid and which ones work unreliably? Sure, you need to think twice before pressing a button, and consult the errata sheet, but it's there for you.
Or a plane that runs software that passed all the basic alpha tests and all the obvious bugs were fixed, but you have no idea what bugs lurk anywhere deeper? You just sat in the pilot chair and during the first 15 minutes you discovered 6 critical bugs. You write them down below 9 others written down by another would-be pilot who sat there before you but gave up.
How much is that list to grow yet?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
hawk, ducking and running
did anyone else notice that AE4 and AE11 appear to be the same bug?
AE4 reads:
"REP MOVS (Repeat/Move a string from one memory location to another) operation in fast string mode continues in that mode when crossing into a page with a different memory type."
AE4 was listed a show stopper.
AE11 reads:
"REP MOVS operation in fast string mode continues in that mode when crossing into a page with a different memory type."
AE11 was listed as Possible effect on performance, but no data loss or corruption.
First of all these seem identical short of the explaining the pneumonic for REP MOVS, secondly it is alarming that the two entries which seemingly identical descriptions got different severity ratings!
proxy
Ha I have been justified in my distaste over Apple's movie to the Intel chip set.
for "$customer" in *
do
"$self".shoot(foot)
done
Athlon64 has 136 bugs and counting.
The fact Intel does not plan to fix any of these bugs does not surprise me at all. Besides the expense of implementing design and fabrication changes, by fixing the probelms they are admitting the probelms really are that bad to begin with, and therefore having one of the older chips is not desireable.
Que angry letters and class action lawsuits.
This is just like whenever the auto industry realizes some minor part may have a slight chance of overheating (no safety risk to people) or other minor issue they make changes to correct. Word gets out and people begin asking if there's going to be a recall and folks with the effected components but no symptoms of the probelm show up at dealerships wanting free replacements with the new part.
Yonah is based on earlier Pentium M designs as well as the Pentium Pro-Pentium III. If you read the errata documents for these processors you will find a lot of the Yonah errata there too. I'm sure they were bugs deemed not worth fixing and thus keep carrying forward. AE2 has existed since the Pentium Pro. It wasn't considered an errata then. Pentium 4 did something different in this case and thus it is an errata now because Pentium 4 is more recent. Section 18.32.1 of IA32 manuals documents this difference. "The behavior when executing near the limit of a 4 GB selector (limit=0xFFFFFFFF) is different between the Pentium Pro and the Pentium 4 family of processors. On the Pentium Pro, instructions which cross the limit -- for example, a two byte instruction such as INC EAX that is encoded as 0xFF 0xC0 starting exactly at the limit faults for a segment violation (a one byte instruction at 0xFFFFFFFF does not cause an exception). Using the Pentium 4 microprocessor family, neither of these situations causes a fault." Pentium III errata: http://download.intel.com/design/PentiumIII/specup dt/24445355.pdf
Banias errata:
http://download.intel.com/design/mobile/SPECUPDT/2 5266519.pdf
Dothan errata:
http://download.intel.com/design/mobile/SPECUPDT/3 0220917.pdf
How much stuff up in space, or in military hardware has these bugs?
Why is it that they lust over a virgin original 80n86 chip, when on probability, the newer stuff is better?
They can test till their teeth fall out, but I've not heard of one shop that treats 'erratas' seriously, and retests with a new test designed for each errata. Could be a worry for some systems.
Next up, they decided that they couldn't verify the whole chip, that this was "beyond" the tools of the time, so they only tested the bits that they felt like testing. So much for black-box engineering. For that matter, so much for thorough testing. They also ONLY did integrated validation, not module validation, which is a big big no-no in the validation world.
They did "Random Instruction Testing" to make sure the different ways of calling an instruction worked, as it is impossible to test every possible calling path. Uhhh - crappy design. So long as a segment of logic is tested and proven, and so long as it is possible to prove that there are no side-effects between segments, you don't have to check every possible calling path for every instruction, you only have to check that each segment of logic complies 100% with the specification and does NOTHING else. This means defining ALL of your invariants and proving that they have the predicted states at all points.
If Intel wants to do stoccastic testing, then it is no wonder that they produce crappy chips, have been dumped by Microsoft (Itanium 2 support was dropped from 64-bit Windows) and are losing market share to other manufacturers. The Monte Carlo method is great for random simulations but will never be useful in producing high-reliability products.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
You forgot to capitalize every fifth word. Your cooperation on this matter in the future would be helpful.
Thanks,
The Insane Rant Police
And did that stop him from buying them, was what I was hinting at.
It is. It's also worth looking at the fact that many of these are listed as having fixes planned, which is in contrast to Intel's policy of only fixing things if they get a lot of hassle from rich people.