Forgot your password?
typodupeerror
Intel iMac Hardware

34 Design Flaws in 20 Days of Intel Core Duo 356

Posted by CmdrTaco
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.

34 Design Flaws in 20 Days of Intel Core Duo

Comments Filter:
  • Up front (Score:5, Interesting)

    by emerrill (110518) on Tuesday January 24, 2006 @12:28PM (#14548936)
    I just think it means that Intel is being more honest about the problems, rather then hiding them til others find them.
    • Re:Up front (Score:3, Interesting)

      by Ucklak (755284)
      They had issues with their first run of the P4's. Remember that there was a BIOS workaround which made it slower than the P3 at the time?
  • Faster (Score:3, Insightful)

    by mysqlrocks (783488) on Tuesday January 24, 2006 @12:29PM (#14548952) Homepage Journal
    Maybe they're just getting faster/better at finding bugs?
    • Re:Faster (Score:5, Funny)

      by Golias (176380) on Tuesday January 24, 2006 @12:34PM (#14549003)
      Shh!!! You're ruining perfectly good FUD!
      • Re:Faster (Score:4, Insightful)

        by diegocgteleline.es (653730) on Tuesday January 24, 2006 @01:42PM (#14549725)
        Indeed! It's like you would say that it's much easier to find bugs just after the first release of the CPU and even easier when it's the debut of a completely new architecture like the Core Duo is!. It'd be like posting links to the AMD errata docs!

        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.
    • Re:Faster (Score:5, Funny)

      by adrianmonk (890071) on Tuesday January 24, 2006 @12:50PM (#14549192)
      Maybe they're just getting faster/better at finding bugs?

      Yeah, I hear they're 2 to 3 times as fast now on the most important bug finding benchmarks.

    • Re:Faster (Score:5, Insightful)

      by Surt (22457) on Tuesday January 24, 2006 @12:52PM (#14549210) Homepage Journal
      It seems likely that given the increasing complexity, the error rate is going to rise proportionally. I mean, how many errors do you expect in a 100,000 transistor chip vs a 100,000,000 transistor chip?
      • Re:Faster (Score:5, Informative)

        by VitaminB52 (550802) on Tuesday January 24, 2006 @01:38PM (#14549693) Journal
        It seems likely that given the increasing complexity, the error rate is going to rise proportionally. I mean, how many errors do you expect in a 100,000 transistor chip vs a 100,000,000 transistor chip?

        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.

      • by jd (1658) <imipak&yahoo,com> on Tuesday January 24, 2006 @03:09PM (#14550497) Homepage Journal
        I'd expect very close to no bugs in either. The costs involved in carrying out comprehensive design analysis, specification verification and implementation verification are virtually zero compared to the cost of producing the initial run of actual silicon.


        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.

        • by OOGG_THE_CAVEMAN (609069) on Tuesday January 24, 2006 @03:59PM (#14550911)
          I think your estimates are *way* off.

          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.
    • by RealProgrammer (723725) on Tuesday January 24, 2006 @12:57PM (#14549262) Homepage Journal
      ... 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).
    • 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
    • Re:Faster (Score:3, Funny)

      by gad_zuki! (70830)
      >>Maybe they're just getting faster/better at finding bugs?

      Right. Its dual core so its twice the bugs found twice as fast. Amazing!
    • Re:Faster (Score:3, Funny)

      by njh (24312)
      Soon they'll be finding the bugs before they leave the factory!
  • by sczimme (603413) on Tuesday January 24, 2006 @12:31PM (#14548970)

    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

    • by Golias (176380) on Tuesday January 24, 2006 @12:40PM (#14549085)
      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.


      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."
    • by laird (2705)
      "this marks one of the first times that Intel released a processor with known bugs"

      Every chip Intel has ever shipped has had errata. This isn't unique to Intel, of course -- every chip ever shipped has had errata. The only news here is that apparently people have found a lot of bugs in this specific chip fairly quickly. But Mac users are a demanding bunch...

      http://www.amd.com/epd/desiging/tsdocs/2.erratashe /index.html [amd.com] lists AMD's errata sheets.
      http://www.rcollins.org/Errata/ErrataSeries.html [rcollins.org] documents some
  • Does anyone know.... (Score:3, Interesting)

    by Jaysyn (203771) <jaysyn+slashdot@gm a i l . c om> on Tuesday January 24, 2006 @12:31PM (#14548971) Homepage Journal
    How many "bugs" are in Athlons?/Duron/Semprons?

    Jaysyn
  • 20 days? (Score:5, Insightful)

    by Anonymous Coward on Tuesday January 24, 2006 @12:32PM (#14548983)
    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.
    • Re:20 days? (Score:2, Interesting)

      by LurkerXXX (667952)
      Sorry, that sounds a little too much like a bug Intel claimed would only affect someone once every 27,000 years [willamette.edu] when it turns out it would hit some folks every 24 days on average. I think I'll stick with AMD.
      • Re:20 days? (Score:5, Informative)

        by Anonymous Coward on Tuesday January 24, 2006 @12:47PM (#14549152)
        And AMD has no bugs in their chips? Here's the Athlon 64 Revision History document off of AMD's own website:

        http://www.amd.com/us-en/assets/content_type/white _papers_and_tech_docs/25759.pdf [amd.com]

        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.
      • I think I'll stick with AMD.

        Obviously AMD processors are perfect and have no bugs. Or Maybe AMD just does not publish those bugs. Which scenario do you find more likely? Personally, I'd much rather that I and developers had access to know what bugs exist rather than just hoping we don't run across one that is well known to AMD, but which they won't release for PR reasons. To me, the fact that this list exists publicly is a selling point for Intel, not a reason to avoid them. Perhaps AMD does publish suc

    • Re:20 days? (Score:4, Funny)

      by Anonymous Coward on Tuesday January 24, 2006 @12:53PM (#14549225)
      I just checked on my P1, and it's really 19.9999999999999999742919319 days, not 20.
    • Also, there's "fixing" and there's "fixing". What needs to be fixed with a new spin of the silicon and what can be fixed with a microcode update?

      It's blog news. Not exactly real news.

      -h-
  • AMD errata (Score:5, Informative)

    by Anonymous Coward on Tuesday January 24, 2006 @12:33PM (#14548992)
    Revision Guide for AMD AthlonTM 64 and AMD OpteronTM Processors [amd.com]. Just for balance. (only two of them are really interesting, #113 is one of them IIRC)
    • Re:AMD errata (Score:3, Interesting)

      by Tucan (60206)
      Just to balance the balance, the AMD document indicates that of 136 listed problems they plan to fix all but about a dozen.
      • Which won't do you any good if you have one of the buggy chips, as you'll still need to purchase the replacement. By which time, the socket will probably have changed and you'll want faster RAM, so you might as well switch vendors.
  • Statistics (Score:3, Interesting)

    by emerrill (110518) on Tuesday January 24, 2006 @12:33PM (#14549000)
    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.
  • by Ninja Programmer (145252) on Tuesday January 24, 2006 @12:34PM (#14549011) Homepage
    ... 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, ...


    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.
  • by toupsie (88295) on Tuesday January 24, 2006 @12:35PM (#14549020) Homepage
    Apple is not the only manufacturer using the Core Duo [notebookreview.com] chip [google.com].
    • 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
  • by catahoula10 (944094) on Tuesday January 24, 2006 @12:36PM (#14549033)
    Why does Apple want to use an intel chip?

    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 ... uh, wait a minute ...
          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. html [ehumorcentral.com])

    I like #7 and #11 myself :-)

  • by tlhIngan (30335) <<slashdot> <at> <worf.net>> on Tuesday January 24, 2006 @12:36PM (#14549035)
    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...
    • My favorite processor errata was for the engineering sample release of the Motorola PowerPC PPC5554 "Copperhead" embedded processor.

      The clock multiplier was software-settable as a 5 bit value. I.E. you could have a multiplier from your crystal of 1x, 2x, 3x, ...., 30x, 31x, 32x.

      Bits 1, 2, and 3 could be set normally. Bits 0 and 4, however, could not be changed.

      At all.

      How they managed to make only the middle 3 bits of a 5 bit register accessible, I have no idea.
  • 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!
  • by Angostura (703910) on Tuesday January 24, 2006 @12:39PM (#14549060)
    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?
  • Sensationalized (Score:2, Insightful)

    by emerrill (110518)
    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.
  • Image Mirror (Score:3, Informative)

    by XMilkProject (935232) on Tuesday January 24, 2006 @12:41PM (#14549089) Homepage
    It's going pretty slow, here's a mirror I setup to the image with list on it: http://www.xmilk.com/coreduo.gif [xmilk.com]
  • by Nom du Keyboard (633989) on Tuesday January 24, 2006 @12:41PM (#14549090)
    The flaw I'm waiting to see:

    Cannot run Windows XP. Classification: Minor.

  • by shawnce (146129) on Tuesday January 24, 2006 @12:44PM (#14549127) Homepage
    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 [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)

    by mrm677 (456727) on Tuesday January 24, 2006 @12:47PM (#14549151)
    The errata for the AMD Opteron is 85 pages long [amd.com]. 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.

    • by wild_berry (448019) on Tuesday January 24, 2006 @01:43PM (#14549743) Journal
      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.
  • by Theovon (109752) on Tuesday January 24, 2006 @12:48PM (#14549160)
    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.)
    • by homer_ca (144738) on Tuesday January 24, 2006 @01:05PM (#14549342)
      "Intel's typical means to mask processor bugs is microcode."

      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.

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

        A workaround isn't considered as a FIX, WONTFIX is wontfix even with published workarounds (including microcode). WONTFIX means that the error won't be fixed at the silicon level, which is the subject of errata papers.

  • 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 iss
  • by Phil John (576633) <phil@@@webstarsltd...com> on Tuesday January 24, 2006 @12:51PM (#14549205)
    Coral Cache of the image [nyud.net]

    Quoth the image: Show stopper, but only observed by Intel so far. Also, any OS developer who codes like this deserves this one.
  • Next week they'll take on the difficult subject of "changelogs" and the mysterious "READMEs" you see everywhere.
  • by jm91509 (161085) on Tuesday January 24, 2006 @01:01PM (#14549295) Homepage
    AE 16:

    Show-stopper but only observed by Intel so far. Also, any OS developer who codes like this deserves this one.
  • "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?

  • by blair1q (305137) on Tuesday January 24, 2006 @01:17PM (#14549458) Journal
    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.
  • 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.

  • by podperson (592944) on Tuesday January 24, 2006 @01:26PM (#14549565) Homepage
    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.
  • One notable bug turned into a features was the A20 Address Line [firingsquad.com] thing.
  • 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 i

If you're not careful, you're going to catch something.

Working...