Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Intel Bug Microsoft Hardware

Flaws In Intel Processors Quietly Patched 311

Posted by kdawson from the probably-broke-drm dept.
Nom du Keyboard writes "According to this article in The Inquirer and this Microsoft Knowledge Base article, a fix for some significant problems in many of Intel's most recent processors has been quietly released — by whom is not clear. Patches are available on Microsoft's site. Affected processors include Core 2 Duo E4000/E6000, Core 2 Quad Q6600, Core 2 Xtreme X6800, XC6700, and XC6800. Details on just what has been fixed are scanty (it's called a 'reliability update'), however, it's probably more important than either Intel or Microsoft is openly admitting." There is no indication that Apple users are affected.
This discussion has been archived. No new comments can be posted.

Flaws In Intel Processors Quietly Patched More

Flaws In Intel Processors Quietly Patched

Comments Filter:
  • If they're releasing the patch so quietly, how will anyone know to apply it?

    • Re: (Score:3, Insightful)

      by Jah-Wren Ryel ( 80510 )

      If they're releasing the patch so quietly, how will anyone know to apply it?
      It's probably a microcode update that your BIOS loads on boot. So, chances are it will be inconspicuously available as part of the next BIOS patch for most systems.

    • Re:my 1.9432534656 cents worth... (Score:4, Insightful)

      by jd ( 1658 ) <`imipak' `at' `yahoo.com'> on Tuesday June 26, 2007 @10:50PM (#19658933) Homepage Journal
      What worries me is the idea of Microsoft Update mucking with the processor in the first place. And what is Genuine Disadvantage going to think of patching a non-Microsoft product anyway?

      • Re:my 1.9432534656 cents worth... (Score:5, Informative)

        by mrsteveman1 ( 1010381 ) on Tuesday June 26, 2007 @11:05PM (#19659035)
        Unless Intel has an update mechanism I'm not aware of, this is a Microcode update, and this is how they are always released.

        And for what its worth it doesn't patch anything, it loads into the processor at boot. Delete the microcode file or remove the OS and the processor will be just as you bought it.

        Just be glad they were smart enough to use such a system where the processor can be updated while running and temporarily, allowing you to revert back to its purchased state.

        • Re: (Score:3, Informative)

          by CTho9305 ( 264265 )
          Just be glad they were smart enough to use such a system where the processor can be updated while running and temporarily, allowing you to revert back to its purchased state.

          It's actually easier to just use an SRAM to hold microcode patches than to incorporate flash memory or other non-volatile reprogrammable storage on the die. Flash requires a special type of transistor, and fuses generally can't be unblown once they're blown (meaning you'd be very limited in how many patches you could ever apply to a gi

          • yes, but... (Score:3, Insightful)

            by r00t ( 33219 )
            Normally a microcode update is flashed into the motherboard with a BIOS update. That is damn close to being the same thing. Not too many people upgrade their BIOS, and fewer still would consider downgrading. Not too many people replace motherboards separately from CPUs, especially these days with a new CPU socket shape being invented every other day.

  • Intel Macs not affected? (Score:5, Insightful)

    by Anonymous Coward on Tuesday June 26, 2007 @10:14PM (#19658631)
    There is no indication that Apple users are affected.

    What, magical pixie faries fixed the Intels in Macs? How could they not be affected?

    • Re: (Score:3, Funny)

      by Anonymous Coward

      Something to do with the unicorn semen and pink elephant droppings.

    • Re:Intel Macs not affected? (Score:5, Insightful)

      by shird ( 566377 ) on Tuesday June 26, 2007 @10:18PM (#19658663) Homepage Journal
      I would guess the bug affects some Ring0 OS type of service/instruction (such as switching in and out of protected mode, paging, faults etc) which MacOS doesn't use. Hence the patch is part of the OS. I speculate that its a workaround in the OS rather than a patch to the actual CPU.

      • correct (Score:5, Informative)

        by r00t ( 33219 ) on Wednesday June 27, 2007 @12:14AM (#19659465) Journal
        The Linux kernel is not currently affected, though some multi-processor apps with homegrown assembly might be.

        The problem is some sort of atomic operation sequence. Somebody let slip a reference to the bug on a mailing list today, without any real details. Probably the details are still under NDA.

        • Re:correct (Score:5, Informative)

          by ocbwilg ( 259828 ) on Wednesday June 27, 2007 @06:11AM (#19661095)
          The Linux kernel is not currently affected, though some multi-processor apps with homegrown assembly might be.

          The problem is some sort of atomic operation sequence. Somebody let slip a reference to the bug on a mailing list today, without any real details. Probably the details are still under NDA.

          I did some digging around, and it actually looks like this is a patch for a bug in the Translation Lookaside Buffer (TLB) that was discovered back in April. Microsoft has released a patch for people running current versions of Windows (Vista, XP, and server 2003) but if you're running anything else then you will have to get a new BIOS update to resolve the issue. If you check the major hardware vendors web sites (HP, IBM, etc) the are offering patches to their system ROMs regardless of the OS.

          I know that it's popular on Slashdot to claim that Linux isn't vulnerable to the same bugs that Microsoft operating systems are, but when it comes to processor bugs (errata, in Intel-speak) that's simply not the case. Linux does make use of the TLBs. Every modern OS does. If you look at the hardware vendors' web sites, you will see that they specifically state that the bug could lead to a BSOD on Windows or a kernel panic on Linux.

      • Re:Intel Macs not affected? (Score:5, Interesting)

        by m.dillon ( 147925 ) on Wednesday June 27, 2007 @12:39PM (#19665545) Homepage
        I couldn't find an exact errata reference but it looks like a ring 0 issue to me too, which means that the OS either doesn't trigger the conditions required or the OS can work around the problem. Some such issues can be fixed in microcode, some have to be dealt with by the operating system.

        There are several known TLB issues that are rather serious which all OSs have to have workarounds for. The most serious issue is that reducing the access permissions in a page table entry (such as turning off the valid bit or making the entry read-only) on one cpu can race another cpu's TLB trying to access that same entry. The race can cut an instruction into two pieces on the other cpu and (if e.g. a read-modify-write instruction) result in fireworks. All modern operating systems have to synchronize page table invalidations across all cpus that might be using the page table in question. So, e.g. in a heavily threaded environment if a page table is shared across three cpus invalidations made in that page table requires all three cpus operating systems to synchronize (usually with an IPI) to guarentee that none of them are accessing memory governed by the page table entry being changed. Kernel virtual memory is even worse, since that is shared by all cpus, which is why its better to just keep a cache of mapped memory instead of constantly mapping and unmapping pages in KVM.

        There are also serious issues with global pages and mixed TLB entries when switching from small pages to large pages, issues when operating in compatibility modes, issues when using address wrapping. Most of these issues only occur with absurd code sequences, such as an instruction which wraps the address space (which will never occur in real life so can be ignored as long as the issue does not cause a failure in the security model). 90% of the errata is not an issue in a nominally running environment.

        -Matt
    • If it is a MS patch how will it fix an OS-independent CPU bug?

      • Linux may not be affected (Score:4, Interesting)

        by laing ( 303349 ) on Tuesday June 26, 2007 @10:43PM (#19658885)
        True story:

        I ran an AMD Athlon in an Asus MB as a Linux server for 4 years with no trouble (other than noticing that mplayer didn't work right). A few years after I decomissioned the MB, I decided to set it up as an XP box for my 4 year old. I was very surprised to discover that it just would not work right. After some troubleshooting, I found that the CPU had a bug in some of the MMX instructions. By this time it was too late to exchange the chip for a functional one so I just threw it away and bought another one from eBay. My 4 year old is happy with his computer.
        • It speaks badly about GCC's reluctance to use MMX/SSE instructions.

          • Re: (Score:2, Informative)

            by monsterlemon ( 713644 )
            No it doesn't. Many (possibly most?) Linux distributions by default target non-MMX processors for the sake of wider compatibility.

            And we're not all Gentoo-style rice, er, I mean D-I-Y-ers who just have to build everything for ourselves.

            In fact, these days I would expect that most Linux users are unlikely to build software for themselves very often, if at all.

    • Re: (Score:2)

      by jmv ( 93421 )
      If they really are not affected (remains to be seen), it could possibly be either because 1) Apple shipped with a batch that isn't affected or 2) OS X isn't doing things that can trigger the bug.

      • Re:Intel Macs not affected? (Score:5, Funny)

        by Fweeky ( 41046 ) on Wednesday June 27, 2007 @12:29AM (#19659547) Homepage
        3) The on-board reality distortion field generator resolves the problem. At the expense of making nearby computers lacking such devices somewhat *less* reliable, of course.

        I swear, our servers have been behaving more strangely since the guy in the next rack over installed a few Mac Mini's; maybe the RDFG's emmit gamma rays from their embedded naked singularity...

    • Re: (Score:2)

      by RuBLed ( 995686 )
      Either that or Apple has released theirs more quietly...
      • Maybe... I recently got an Apple update that took Tiger from 10.4.9 to 10.4.10 on my Intel Macbook and Intel iMac. Maybe this release had the patch?

    • Re:Intel Macs not affected? (Score:4, Funny)

      by Kingrames ( 858416 ) on Tuesday June 26, 2007 @10:22PM (#19658693)
      It's not that they're not affected. It's that apple fanboys won't admit to it.

      • Re:Intel Macs not affected? (Score:4, Informative)

        by ben there... ( 946946 ) on Wednesday June 27, 2007 @01:14AM (#19659751) Journal
        This sounds like it doesn't affect much of anyone with a real, existing Core 2 Duo, at least according to the summary...

        Affected processors include Core 2 Duo E4000/E6000, Core 2 Quad Q6600, Core 2 Xtreme X6800, XC6700, and XC6800.

        E4000 - doesn't exist
        E6000 - doesn't exist
        Q6600 - k, this one does exist
        X6800 - this one exists too
        XC6700 - doesn't exist
        XC6800 - doesn't exist

        Of course, they probably meant E4000 and E6000 series, and maybe they meant QX6700 and QX6800...

        I guess it was the inquirer's [216.239.51.104] fault [theinquirer.net]. But they probably could have just said "all Core 2 Duos, Extremes, and Quads."

    • Why Mac OSX not affected (Score:5, Funny)

      by Anonymous Coward on Tuesday June 26, 2007 @10:29PM (#19658753)
      Mac OSX does not make use of the new x86 BNDOVR opcode, unlike Windows which is dependent on it.

    • Well, it only affects two models of the Core 2 Duos, which is the only processor that Apple uses for all its Intel Macs except the Xserve (Xeon) and the Mac mini (first-generation Core Duo, which is not affected). So, assuming Apple didn't use either the E4000 or the E6000 Core 2 Duo processors, that would explain why they are not affected.

      However, I do think the situation is interesting when we look at the Xserve, since they use Xeons. The article notes several affected models of them, which it says is ju

      • Well, it only affects two models of the Core 2 Duos, which is the only processor that Apple uses for all its Intel Macs except the Xserve (Xeon) and the Mac mini (first-generation Core Duo, which is not affected).

        Well, I am sure I won't be the only person to point this out, but Apple does not use the Core 2 Duos in the MacPro towers, either. They use Xeons.

      • The article is stupid because it's the Inquirer, but they mean the Entire E4000 and E6000 series. What they really mean to say is that every single Core 2 Duo processor is affected.

    • Re:Intel Macs not affected? (Score:4, Insightful)

      by crayz ( 1056 ) on Tuesday June 26, 2007 @11:24PM (#19659159) Homepage
      It's funny that everyone is asking where the Apple patch is. How about: where's the Linux patch?
    • Good grief, put two and two together. No information about what the patch does, it's a Microsoft update, and Apple and Linux aren't affected. It's the DRM, stupid! -- (borrowed from the Bill Clinton 1992 campaign).
      • Looks like linux systems on Intel can generate a kernel panic. However, it would be interesting to know if this is only on systems from big vendors that also ship windows software (i.e. Dell), because the microsoft update filenames all have the word "genuine" in them. Big vendors use custom bios that may be the same whether they are shipping a linux server or a microsoft server, and ship versions of windows that will only run on their machines.

        Given the level of secrecy that Intel and Microsoft are givi

        • Re:Ooops, I'm the blind one (Score:5, Insightful)

          by afaik_ianal ( 918433 ) on Wednesday June 27, 2007 @12:50AM (#19659621)

          Given the level of secrecy that Intel and Microsoft are giving to the nature of the bug, I still think that DRM is the true culprit.


          And given that I have no evidence either way, it must be the fairies. What kind of an argument is that? If they were being so secretive to hide the nature of the patches, why would they go and label them in the fricking file names?

          Isn't it more plausible that the file names have the word "genuine" in them because like many patches, they're only available to activated windows boxes, and that it's just some random bug in the microcode being fixed?

          I think you've had the tinfoil hat on a little bit too long.

          • Re:Ooops, I'm the blind one (Score:4, Informative)

            by ocbwilg ( 259828 ) on Wednesday June 27, 2007 @06:13AM (#19661103)
            Isn't it more plausible that the file names have the word "genuine" in them because like many patches, they're only available to activated windows boxes, and that it's just some random bug in the microcode being fixed?

            The bug in question is the bug in the TLB that was discovered back in April. Here's HP's page [hp.com] on it. I think that the only reason it's news today is because Microsoft has either just released or re-released a patch to fix the issue on Windows boxes.

        • Re: (Score:3, Informative)

          by cowbutt ( 21077 )
          ...because the microsoft update filenames all have the word "genuine" in them

          No, the phrase 'genuineintel' is used, because that's how Intel chips identify themselves [wikipedia.org] using the CPUID opcode.

    • Re: (Score:2)

      by dwater ( 72834 )
      Don't ask awkward questions. Just be thankful you use awesomely reliably Apple products and not those other (spit) ones.
    • Once installed inside an Apple case, Intel CPUs are immediately protected by the Jobsian Reality Distortion Field (JRDF).

      Install Intel in a PC, you've got problems.

      Install Intel in a Mac and... Boom! No problems.

      And you want an iPhone.

  • Microcode (Score:5, Informative)

    by bblount ( 976092 ) on Tuesday June 26, 2007 @10:20PM (#19658679)
    This patch affects the microcode, which are the underlying machine instructions: http://en.wikipedia.org/wiki/Microcode [wikipedia.org]

    How could this not affect Intel Macs? They use the same machine instructions that everyone else does!
    • Microcode bugs will only bite you if you execute certain instruction sequences that trigger them.

      Perhaps this only happens on MS and not on Macs.


    • Uhh, you can flash the CPU Microcode from within a Microsoft OS?!? [Other than DOS?!?]

      Wouldn't this pose like the Mother of All Possible Challenges to the Black Hat community - how to right a worm that could flash CPU's, thereby rendering nearly limitless power over every possible sandboxing or anti-virus countermeasure?

      Kinda the Helen of Troy [or Anne Boleyn [sho.com]] of Hax0r/Crax0r Wet Dreams?

      Seriously - how can you hope to maintain the illusion of Virtual Machines if you can write to the microcode?

      • Re:flash the CPU Microcode - YIKES! (Score:5, Insightful)

        by andreyw ( 798182 ) on Tuesday June 26, 2007 @10:47PM (#19658901) Homepage
        Uh, read the fine documentation. Microcode updates don't survice power-off. Nevermind that the microcode is a blackbox format, dependent on the chip and likely with a bajillion signatures the silicon checks.

        • Re: (Score:3, Insightful)

          by timmarhy ( 659436 )
          1. blackbox does not make it saver 2. so what if it doesn't survive a boot, just reprogram it with your hacked code every boot

          • Re:flash the CPU Microcode - YIKES! (Score:4, Insightful)

            by GauteL ( 29207 ) on Wednesday June 27, 2007 @05:09AM (#19660829)
            "so what if it doesn't survive a boot, just reprogram it with your hacked code every boot"

            Which makes it no worse than any other hack, virus or worm. You can already take complete control over the computer without resorting to microcode.

            If it had been permanent and survived reboots, then a complete format and reinstall would not remove the hack. That would have been scary indeed, but luckily that is not the case.

    • Re: (Score:3, Insightful)

      by suv4x4 ( 956391 )
      How could this not affect Intel Macs? They use the same machine instructions that everyone else does!

      Question is, how come you patch microcode hardware flaw with a software patch - is this affecting performance? Possibly.

      About the Macs not being affected: that was funny. Given how secretive the MS/Intel patches are, and we know Apple is totally open about stuff like that, right?

  • Oh come on, it's nothing (Score:5, Funny)

    by Anonymous Coward on Tuesday June 26, 2007 @10:21PM (#19658691)
    With two such large, trustworthy, open, and reliable organizations involved, which have always looked after the general well being of the industry because what's good us is good for them, do we really need to worry ?

  • ah, time to dig up the bluewave tagline file... (Score:5, Funny)

    by jollyreaper ( 513215 ) on Tuesday June 26, 2007 @10:26PM (#19658721)
    How many Pentium designers does it take to screw in a light bulb? 1.94
    Pentiums and Deodorants - When being close is all that matters
    Highlander Pentium: There can be only 1.0101002913491!
    Talking Barbie and the Pentium-90 agree! "Math is hard!"
    "Go forth and multiply... divide only if not on a Pentium..."
    "I am Pentium of Borg--prepare to be approximated"
    Pentium: Making tomorrow's mistakes today
    Pentium slogan: Why Do You Think It's Called *Floating* Point?
    Pentium slogan: Nearly 300 correct opcodes!

    Yeah, I know that Intel bashing is old, that's why I used old jokes.

    • Re:ah, time to dig up the bluewave tagline file... (Score:4, Funny)

      by minion ( 162631 ) on Tuesday June 26, 2007 @10:44PM (#19658889)
      Man, it was just last week I finally decided to clear out all pre-95 taglines from my BlueWave ONELINER.TXT file. Doh!
       
      I do have these gems still though:
       
      Win2k: "It's not so much that it's only 65,000 bugs, it's just that they stopped at 65,535 to prevent an overflow."
       
      Sun believes the only place for 63,000 bugs is a rain forest.
       

  • Some more details (Score:5, Informative)

    by macemoneta ( 154740 ) on Tuesday June 26, 2007 @10:31PM (#19658773) Homepage
    I had submitted some additional details in a rejected submission:

    Two months ago, Intel introduced microcode updates for all systems with an Intel® Core(TM) 2 Duo processor [ibm.com]. According to an HP Tech Support Document [hp.com]:

    While the implications of the issue are difficult to quantify, any of the following symptoms can occur:

    * The system may stop responding to keyboard or mouse input.
    * A system operating in a Microsoft Windows environment may generate a blue screen.
    * A system operating in a Linux environment may generate a kernel panic.

    This was the first I had heard of this; probably a good time to check for BIOS or microcode [urbanmyth.org] updates."

    The HP link also indicates the nature of the problem, which should not be OS specific:

    This Intel microcode update addresses an improper Translation Lookaside Buffer (TLB) invalidation that may result in unpredictable system behavior such as system hangs or incorrect data.

    • Re:Some more details (Score:5, Informative)

      by ibentmywookie ( 819547 ) on Tuesday June 26, 2007 @10:51PM (#19658935)

      For those that are wondering, the Translation Lookaside Buffer is what is used to map Virtual Addresses to physical page addresses. The TLB is a cache of recent translations between Virtual and Physical addresses. So what could happen with incorrect invalidation is that the WRONG physical page could be resolved and bogus data accessed by the operating system.

      More here [wikipedia.org].

    • "* A system operating in a Microsoft Windows environment may generate a blue screen."

      So this is a "sky is blue" type of error then?
    • Yes, it looks like MS is releasing this to cover systems that aren't expected to get BIOS updates or to be used in lieu of a BIOS update.

      Still seems odd to me, but the quietness of the issue doesn't encourage any suspicion for me.

      MS often releases non-security and non-critical updates in a graduated manner:
      First, you must call PSS to be able to download the patch. MS just wants to be sure the patch fixes the problem. You're a beta tester.
      Next, they release the patch for public download. Affected users wi

    • Linux not affected (Score:3, Informative)

      by alanw ( 1822 ) *

      The HP link also indicates the nature of the problem, which should not be OS specific: This Intel microcode update addresses an improper Translation Lookaside Buffer (TLB) invalidation that may result in unpredictable system behavior such as system hangs or incorrect data.

      This recent posting to the Linux Kernel Mailing List [google.co.uk] by Andi Kleen states that Linux is not affected.

      > It's been a while; is there any sign of the ucode updates being
      > available, especially in light of the C2D/Q incorrect TLB invalidation
      > + recent ucode to fix this?

      That microcode update is not needed on any recent Linux kernel; it flushes
      the TLBs in a way that is fine.

  • My company was contacted by Dell about a month ago regarding our rack mount server that uses a 5100-series CPU. However, they told me it only affects Windows.
    • That's because Dell is pretty much only "Windows only". Why should they care about anything else?

      • Re:Dell told me "Windows only" (Score:4, Informative)

        by whoever57 ( 658626 ) on Tuesday June 26, 2007 @10:41PM (#19658869) Journal

        That's because Dell is pretty much only "Windows only". Why should they care about anything else?
        You do know that Dell offers Red Hat Linux on most if not all servers, don't you?
        • You're right, I wasn't really thinking server. I was thinking more about the non-existent Linux 'support' they have on the workstation/desktop side. I've never had to contact server support for linux so I don't know how well or if they give a rat's arse about those customers.

          • Re: (Score:3, Informative)

            by ArbitraryConstant ( 763964 )
            My dealings with Dell on the server side have been pretty satisfactory, even running Slackware or OpenBSD.

            My only complaint is the satisfaction survey they send you after the issue is resolved (not kidding).
      • No its because Dell doesn't want to have to release a BIOS update for all the affected systems, which would be any system that uses socket 775 or 771 motherboards made/sold in the last 3-5 years. So they basically say that it is a Windows only issue so they can use the built in Windows microcode loader which layers the microcode onto the CPU at every boot (since it is lost when it reboots).
  • Patches distributed by Microsoft, for microsoft products. Seems like an MS problem rather than an Intel issue, which kind of makes the title of this article misleading.
    However, this sounds very similar to the issue with Prescott CPU's and XP SP2, where an installation on a system with a CPU below stepping 8 would hard freeze on restart after the initial setup. In that case the fix was a BIOS update OR disabling L1 and L2 cache.
    • I work at a company that makes operating systems. It is not uncommon for us to issue workarounds when hardware problems are found with processors. Just because MS is issuing a patch doesnt mean that it is their fault.
      • So apparently MS has a dll (or in XP's case, a .sys) file that has the capability of identifying a given processor and writing microcode updates to it. In one respect, I can see how this can be useful; on the other respect, if it ever got hacked we could be left with a whole lot of junk CPU's that couldn't be booted from.
        • I am not familiar with these updates, but I doubt that this is whats going on, it seems unlikely that MS is writing microcode updates for intel processors. Its probably modifications to the windows kernel to work around some bugs. As an oversimplified example one time I was working on a project and it was discovered that one of the processors we build for could generate a spurious interrupt under rare circumstances as a result of a tlb miss but the cache being hit at the same time. (it was more complicate

        • Re: (Score:3, Informative)

          by atrus ( 73476 )
          Linux has it too (microcode updates have been available since the Pentium Pro days). The microcode update is soft though, the original microcode is restored on a reboot. The best fix would be a relevant BIOS update which loads the patched microcode much earlier.
  • I would be interesting to find how long Intel knew about this and if it had anything to do with rushing to market to compete with AMD and their recent price cuts.

    It's sort of chicken and eggish when talking hamburger, but is the defect because of the price cuts to compete or is the price cuts because of the flaw? Or is it totally unrelated with either and I'm just throwing balls at the side of the barn and missing?

    I am wondering though, doe this mean I would have a CPU that doesn't do everything it was supp
  • It might NOT affect Macs, because of the way the OSX kernel handles specific failures. Remember when the F00F bug came out, Linus himself quickly came up with a Linux patch that mapped it over to (IIRC) a page fault, which then was handled separately. DOS machines just died.

    For this PARTICULAR microcode issue, OSX _may_ do something interesting with it, and so not be affected. Or, they simply never tested/validated it, and so Apple has no patch.

  • CPU's are Emulators (Score:5, Informative)

    by Effugas ( 2378 ) * on Tuesday June 26, 2007 @11:01PM (#19659005) Homepage
    So here's the deal.

    Intel processors don't directly execute instructions anymore. They translate x86 into a series of other operations -- an internal code, if you will. Sometimes there are bugs in the code that's generated. Microcode patches address those bugs.

  • Slashdot readers and microcode (Score:5, Insightful)

    by mrsteveman1 ( 1010381 ) on Tuesday June 26, 2007 @11:14PM (#19659095)
    After reading this thread its amazing to me how many Slashdot readers don't know how microcode works, making broad statements about how patching a processor is impossible without an EEPROM burner, or using a DOS boot disk.

  • Waxing nostalgic (Score:3, Interesting)

    by Enderandrew ( 866215 ) <enderandrewNO@SPAMgmail.com> on Tuesday June 26, 2007 @11:17PM (#19659115) Homepage Journal
    Intel was just waxing nostalgic and wanted to remember the good only days.

    http://en.wikipedia.org/wiki/Pentium_FDIV_bug [wikipedia.org]

  • Asleep at the wheel (Score:5, Insightful)

    by edwardpickman ( 965122 ) on Tuesday June 26, 2007 @11:45PM (#19659285)
    What's up with the Moderators? I constantly see posts that say the exact opposite thing both modded Informative or Insightful. We need a category "Incorrect". If the Moderators don't know the correct answer they should refrain from moderating either Insightful or Informative. It may be informing but the post is informing people with incorrect information.

    • Re:Asleep at the wheel (Score:5, Funny)

      by Beardo the Bearded ( 321478 ) on Wednesday June 27, 2007 @12:05AM (#19659403)
      It's how you Karma Whore. Observe:

      This is a serious problem for Java and .NET as well, since both of those virtual machines have to translate this incorrect opcode into the correct functionality.

      What this patch fails to realize is the problems with the instruction listed on Intel's website. A similar bug in all x86 chips manufactured since 2004 (yes, really!) requires that most compilers have to work around it. (The patch in BCB wasn't ready until late 2005, which is what lead to a 15% drop in their market share.) It has become a problem in real-world applications requiring time-critical code. It may not mean much to most "high-level" programmers, but SOME of us still get into the assembly code every now and then. It's a real nightmare, and it's not something that you expect from a company like Intel.

      I refer you to the errata at http://docs.intel.com/kb2004/hwbugs/knownissues.ht ml [intel.com]

      See what I mean? It totally looks like I know what I'm saying, but it's a complete fabrication. If I didn't put these lines bookmarking it as just plain dumbassedness, then I'd probably get modded up for it. Hell, I'll probably STILL get modded up. Some lazy mods (myself included) treat the mod points like a hot potato, or leprosy.

      I think this post is funny, but then again, it's well past my bed-time.

  • Blah - Old News (Score:3, Interesting)

    by FuegoFuerte ( 247200 ) on Wednesday June 27, 2007 @12:29AM (#19659549)
    Blah I say. Blah. This is old news. I first read about it over a month ago when Dell shipped a "critical update" for some of their laptops for this issue. Check out this HP advisory from a couple weeks ago:

    http://h20000.www2.hp.com/bizsupport/TechSupport/D ocument.jsp?objectID=c01038053 [hp.com]

    Dell released an update for PE2950 servers around the same time.

    So again I say, Blah.

    *YAWN*

  • Errata (Score:4, Informative)

    by oglueck ( 235089 ) on Wednesday June 27, 2007 @02:51AM (#19660267) Homepage
    Intel has released an errata document [intel.com].
    For June 2007 it lists 3 new errata:

    AH106
    A memory access may get a wrong memory type following a #GP due to WRMSR to an MTRR mask.

    AH107
    PMI while LBR freeze enabled may result in old/out-of-date LBR information

    AH5P
    VTPR may lead to a system hang

    However, the document states that there are no fixes available. So it's probably not what MS/Intel is addressing here.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (7) Well, it's an excellent idea, but it would make the compilers too hard to write.

Close