Slashdot Mirror
Flaws In Intel Processors Quietly Patched
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.
If they're releasing the patch so quietly, how will anyone know to apply it?
If my call is important, why am I talking to a recording?
Debian AMD64: Check. AMD X2: Check. Clear
There is no indication that Apple users are affected.
What, magical pixie faries fixed the Intels in Macs? How could they not be affected?
It's hard to get the errata for intel's processors when your a post SI test engineer, working for intel. Marketing seems to keep a tight fist on bad news.
Smells like Digital Rights Management to me.
You never know given the vague wording of the patch.
If it is a MS patch how will it fix an OS-independent CPU bug?
Engineering is the art of compromise.
This patch affects the microcode, which are the underlying machine instructions: http://en.wikipedia.org/wiki/Microcode
How could this not affect Intel Macs? They use the same machine instructions that everyone else does!
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 ?
Perhaps this only happens on MS and not on Macs.
Engineering is the art of compromise.
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.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
Mac OSX does not make use of the new x86 BNDOVR opcode, unlike Windows which is dependent on it.
Two months ago, Intel introduced microcode updates for all systems with an Intel® Core(TM) 2 Duo processor. According to an HP Tech Support Document:
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 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.
Can You Say Linux? I Knew That You Could.
There was a microcode update released as part of system BIOSes a couple months back; this may be a workaround for people who cannot or will not update their system BIOS.
D ocument.jsp?objectID=c01020735&dimid=908755463&dic id=alr_apr07&jumpid=em_alerts/us/apr07/all/xbu/ema ilsubid/mrm/mcc/loc/rbu_category/alerts
The most complete information I could find was posted as part of HP's BIOS update: http://h20000.www2.hp.com/bizsupport/TechSupport/
Looks like the primary problem is system stability, though I suspect imaginative people could probably find a security vulnerability with the TLB.
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.
The real "Libtards" are the Libertarians!
maybe they're working on testing a system for installing software to processors. why build a machine to do it when you can test it in theory on tons of free machines? maybe microsoft and intel are working on the next big shift in our software and processors. modern processors are gaining cores rapidly, why not have these cores programmed to execute specific operations?
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] of Hax0r/Crax0r Wet Dreams?
Seriously - how can you hope to maintain the illusion of Virtual Machines if you can write to the microcode?
Microcode updates get released all the time. XP SP2 shipped with around 100 microcode patches for various processors, and that wasn't even all the updates available. The update driver had a limited catalog so only the most popular updates could be included. I don't know how many updates ship with Vista but there had to have been dozens more over the last few years.
Comment removed based on user account deletion
> has been quietly released...
:-)
One of the files in the update is called Update-bf.mum. That's why they're keeping it quiet
Because Macs don't have bugs.... ever.... ... ... ...
They have "error codes". 32767 to be exact.
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.
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.
Typically it is only sequences of instructions that would trigger these bugs. In other words, the CPU has to be in a certain state to trigger the bug. Some OSs will never get in that state. The bugs are surely something like this because otherwise crashes would be far more common than we see.
The reason why I mention cache handlers is because those are notoriously tricky and have proven buggy before. The Core Duo 2 CPUs need new cache handlers to handle the dual (and more) cores and thus this area is more likely to be buggy.
Engineering is the art of compromise.
Assuming this is the same microcode update that I think it is, anyone on a nVidia 680i motherboard who has kept up with the BIOS releases (namely, P28) has already fixed this.
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 supposed to do before the patch and flaw was know? I mean does the patch limit the processor or screw with it's abilities in anyway other then stopping errors? I'm dieing to know.
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.
I want to delete my account but Slashdot doesn't allow it.
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.
Haven't you seen the commercials? It just works don't ask questions.
If they were, it would be called the iPatch.
BEWARE: There is a bug in this microcode update that causes problems in some realtime video and audio applications, for instance, Pro Tools.
At least, HP's new BIOS have this issue. Caused a major headache tracking this one down. Has something to do with erratic time values being returned when calls are made at high resolutions (for instance near 30 milliseconds...)
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.
that this neither comes with a silver platter, or chilled champagne. I know when this realization dawned on me, my monocle popped out and rolled under my desk. My gentleman's gentleman, Wheatley, has noted his displeasure with your oversight while remedying the situation.
Intel was just waxing nostalgic and wanted to remember the good only days.
http://en.wikipedia.org/wiki/Pentium_FDIV_bug
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
News of this errata fix is posted on The Inquirer, in a Microsoft Knowledge Base article, and now Slashdot. I wouldn't call this "quietly released."
Is because they have such small user base, naturally. ;)
If you don't know what AltaVista is (was), get off my lawn.
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.
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).
3 things about computers: they're alive, they're self-aware, and they hate your guts.
You cann0t patch transistors of a microprocessor. Anyone remember the FDIV bug?
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.
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 giving to the nature of the bug, I still think that DRM is the true culprit.
3 things about computers: they're alive, they're self-aware, and they hate your guts.
....patch for problem no one has noticed yet released quietly. *sound of one hand clapping*
It's a bug in motherboard chipset.
The BIOS hack uses SMM/SMI (system management mode) to emulate one clock chip by using a different one. (eeew)
It causes massive problems for real-time code.
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:
D ocument.jsp?objectID=c01038053
http://h20000.www2.hp.com/bizsupport/TechSupport/
Dell released an update for PE2950 servers around the same time.
So again I say, Blah.
*YAWN*
Hello, is this News for Lamers, Stuff that we don't care about, or what?
Wow and iTunes occasional blue screen as well when launching. At least I have noticed this but its not often.
http://saveie6.com/
All the constant blabbering about this iPhone thing, article upon article about a GSM phone, and now this:
"There is no indication that Apple users are affected."
Who cares about Linux?
---
"The chances of a demonic possession spreading are remote -- relax."
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.
This microcode update is being provided to eliminate two issues:
A possible processor marginality
A potential source of unpredictable system behavior
For my system, there has already been one other update released since the one that fixed the microcode.
Also interesting to note what that they mention on the same page:
This microcode update has no performance impact and is a complete solution for these issues.
as boot camp is just a boot loader, why wouldn't this bug also affect mac computers running windows (presumably only when running windows) ?
Well, Intel does release these every so often -- the fact that Intel released updated microcode is hardly news. How these patches work is that Intel releases the Microcode. OS suppliers then take that Microcode and incorporate it into their OS's microcode update facility -- it's already released for Linux for crying out loud! The odds are that Apple have included this Microcode update, it's just been rolled into one of the other updates that nobody's noticed yet.
These updates can also be loaded into your BIOS too so they're loaded prior to OS startup; it's just that it's usually a lot easier to update OS installations than reflashing lots of different BIOS variants. However, I suspect this is exactly what Apple have done -- they've incorporated this microcode update into their EFI updates and/or will include this version in the next round of updates.
About the only surprising thing is that Micosoft have actually wrapped it up and released it. Usually they don't bother unless they've actually had issues that are fixed by microcode updates.
My favorite Pentium bug was the "F00F" bug: create a file containing four bytes, F0 0F C7 C8 in hex, and save it with a .com extension. Double-click, and the whole thing just immediately stops. No error message, no blue screen of death, nothing.
Linux has a workaround for this (I think it'll just segfault or something), but NT doesn't. Never tried it on 2000, and of course later CPUs aren't susceptible.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
a) It won't change the BIOS...how could it?
b) If it affects the CPU then it could also affect Linux. When will a patch be available for my Linux servers? I don't feel safe running them.
No sig today...
Ummm.. Virus' dont' survive power off either, they simply reload themselves on the next reboot...
No sig today...
Knowledge is not important, but your willingness to learn new things is.
Do you know how a patch-clamp amplifier works when recording whole-cell in a voltage-clamp mode?
Do you know how the inductively-coupled atomic emission spectroscope works, and how it is different from an atomic absorption spectroscope?
Do you know how to calculate PI by hand to n-th decimal place?
"We are Pentium of Borg. Division is futile. Prepare to be approximated."
Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
Intel has released an errata document.
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.
Just looking at the requirements, XP SP1 not supported. And no I have no plans to upgrade. Waitin for the bios upgrade.
1) The Pentium FDIV bug produced an incorrect answer in 1 in 9 billion double precision floating point divides. It did not affect integer divides.
2) The answer always contained at least 14 correct significant bits (usually more, but an error in the 15th significant bit was the worst case). The means that single precision calculations were almost invariably correct.
3) Any hack to solve the problem would have been hundreds of times slower than just living with a small error in so few calculations.
4) All games today get by just fine using single precision floats for rendering.
5) It took a guy (Thomas Nicely) with a Ph.D. doing heavy research in computational number theory to find it, yet you found it while working on a game in QuickBasic.
I think Nicely said it best in his FDIV flaw FAQ:and also:
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
AI88. Microcode Updates Performed During VMX Non-root Operation Could Result in Unexpected Behavior
Problem: When Intel® Virtualization Technology is enabled, microcode updates are allowed only during VMX root operations. Attempts to apply microcode updates while in VMX non-root operation should be silently ignored. Due to this erratum, the processor may allow microcode updates during VMX nonroot operations if not explicitly prevented by the host software. Implication: Microcode updates performed in non-root operation may result in unexpected system behavior.
Workaround: Host software should intercept and prevent loads to IA32_BIOS_UPDT_TRIG MSR (79H) during VMX non-root operations. There are two mechanism that can be used (1) Enabling MSR access protection in the VM-execution controls or (2) Enabling selective MSR protection of IA32_BIOS_UPDT_TRIG MSR. Status: For the steppings affected, see the Summary Tables of Changes.
Microcode updates are applied to CPUs are done all the time via BIOS updates. The only element of this that is newsworthy is that this microcode update is applicable to Windows only (it would seem) as Microsoft are the ones providing it. Since it is not rated as a critical update (or even an automatic one) and the BIOS makers have seen fit to omit it from their own BIOS updates (despite the fact that Windows has a dominant market share), the smart money is on it patching something which is both very rare and very difficult to reproduce.
This news is pure FUD, because this update is a reliable update and NOT a secuity update.
Some drink at the fountain of knowledge. Others just gargle.
(Disclaimer; I am not an expert on the subject matter, take the following with a pinch of salt).
Consider this; do you really have x86 CPU "hardware" in your Intel-based PC? This depends on how you define "hardware".
As far as I'm aware, all modern Intel "x86" CPUs (Pentium Pro/Pentium II onwards) have a RISC core. They have to convert the long and irregular (i.e. nothing like RISC) x86 code into the native RISC instruction set via microcode. So it could reasonably be argued that the CPUs aren't actually executing the x86 instructions themselves in hardware.
Of course, all this is transparent to the user; as far as they are concerned, the CPU *is* "hardware", and I'm not sure if any of this is even visible from a system-designer's point of view (i.e. the processor is- I'd assume- still a "black box" for this purpose).
Anyway, I assume they did this because- even with the overhead of translation and the added complexity- it would still have made optimising the design much easier. Generally speaking, this is one of the major benefits of RISC design; x86's CISC instructions (i.e. long, complex and irregular) would have presented a major headache to Intel's engineers.
It's notable that the older Pentium-I had a CISC core; so internally the chip was *very* different from the Pentium Pro/P-II. I assume this means that it *was* based around the x86 instruction set to some extent, although I don't know how much- if any- conversion or translation of instructions via microcode was involved. I suspect that because the core hardware would have been based round the x86 instructions themselves and less reliant on microcode, fixing bugs (etc) via microcode would have been far harder- if it was possible at all.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Here is a direct link for the Windows XP version for all people who detest WGA:c f22-f333-4469-8209-fafc2d084e8f/WindowsXP-KB936357 -x86-ENU.exe
http://download.microsoft.com/download/3/5/e/35ec
this Slashdot Meta Comment. Yes, it's also linked in my sig.
Best Slashdot Co
We now know why the National Security Agency has gone to Congress with a supplemental budget request of 800 Million Dollars for a power system upgrade.
E Proelio Veritas.
Here is a story from April 29th.. Which actually tells you WHAT the microcode fixes http://www.rage3d.com/board/showthread.php?threadi d=33889730
I don't need to test my programs.. I have an error correcting modem.
Relax, he thinks a mythical being talks to him (did you read his laughable story?), so obviously he's not, how do I say this politely...
The mobile Core 2 Duo chips (T7xxx) are 64-bit, but missing from the list as well.
the link is a 'joke'.
The Kruger Dunning explains most post on
1. Intel and AMD have been releasing microcode updates for ages.
2. The current list of serious bugs in cpus that could cause crashes on AMD and Intel CPUs is reaching hundereds now. Every operating system has workarounds for bugs.
3. It's nothing new. There are workarounds for bugs in MIPS, SPARC, VAX, etc.
4. Core 2 is the buggiest CPU I've worked with this far, the TLB behavior on it is weird beyond belief.
5. There will be _more_ of this kind of bugs in future CPUs, considering the weird things CPU designers have to do to squeeze out more performance in less tolerances, with shorter product life cycles.
6. Update your BIOS and you'll be fine in most cases.
All operating systems at the time quickly implemented a workaround for the bug.
Wikipedia link
More than you ever wanted to know about the F00F bug
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Well, if that's true, and assuming that anti-virus software can become sophisticated enough to recognize microcode-flashing attempts on reboot, then here are two possible hax0r/crax0r countterattacks:
1) Target machines, like servers, whose uptimes are measured in months, or even years [and if M$FT forces reboots for critical updates every Tuesday, forcing their uptimes down into the 7-day range, then target Intel/AMD servers with longer up-times, like FreeBSD, Linux, OSX, etc].
2) Flash the motherboard BIOS with hax0red/crax0red code, so that it will flash the CPU microcode [on every reboot, if necessary]. Or heck, flash the video [or sound] card's BIOS with with hax0red/crax0red code, and let them corrupt the CPU [on every reboot, if necessary].
But either way, the very fact that you can flash this stuff from within the OS just scares the bejeebus out of me.
because it wouldn't scan to call it the 585.89123230945390 instead of the 586.
if this is supposed to be a new economy, how come they still want my old fashioned money?
That exploit wouldn't work because the OS would trap the invalid page access and generate a blue screen or kernel panic.
Just because the TLB returns an erroneous translation doesn't mean that the OS isn't still going to check to make sure your process has access to the address space in question.
:(){
Not to mention that around the same time (and even later on) AMD was pumping out crappy processors that did floating point approximations so horrible you could be pretty sure to find the errors pretty much every time. But nobody cared.
(glibc's tests always failed on AMDs)
What would be fascinating to know here is if this affects the performance of the processor itself. Sometimes things are fixed by inserting wait states, or other, more inefficient ways, of performing the function. What if someone performed benchmarks before and after this patch, and found a 2% degradation in performance? Would that be news?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
(just got this in my mail from the OpenBSD mailing list)
d t/31327914.pdf
d uo_errata__2006_01_21__full.gif
Various developers are busy implimenting workarounds for serious bugs
in Intel's Core 2 cpu.
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.
As is typical, BIOS vendors will be very late providing workarounds /
fixes for these processors bugs. Some bugs are unfixable and cannot
be worked around. Intel only provides detailed fixes to BIOS vendors
and large operating system groups. Open Source operating systems are
largely left in the cold.
Full (current) errata from Intel:
http://download.intel.com/design/processor/specup
- We bet there are many more errata not yet announced -- every month
this file gets larger.
- Intel understates the impact of these erraata very significantly.
Almost all operating systems will run into these bugs.
- Basically the MMU simply does not operate as specified/implimented
in previous generations of x86 hardware. It is not just buggy, but
Intel has gone further and defined "new ways to handle page tables"
(see page 58).
- Some of these bugs are along the lines of "buffer overflow"; where
a write-protect or non-execute bit for a page table entry is ignored.
Others are floating point instruction non-coherencies, or memory
corruptions -- outside of the range of permitted writing for the
process -- running common instruction sequences.
- All of this is just unbelievable to many of us.
An easier summary document for some people to read:
http://www.geek.com/images/geeknews/2006Jan/core_
Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare
the hell out of us. Some of these are things that cannot be fixed in
running code, and some are things that every operating system will do
until about mid-2008, because that is how the MMU has always been
managed on all generations of Intel/AMD/whoeverelse hardware. Now
Intel is telling people to manage the MMU's TLB flushes in a new and
different way. Yet even if we do so, some of the errata listed are
unaffected by doing so.
As I said before, hiding in this list are 20-30 bugs that cannot be
worked around by operating systems, and will be potentially
exploitable. I would bet a lot of money that at least 2-3 of them
are.
For instance, AI90 is exploitable on some operating systems (but not
OpenBSD running default binaries).
At this time, I cannot recommend purchase of any machines based on the
Intel Core 2 until these issues are dealt with (which I suspect will
take more than a year). Intel must be come more transparent.
(While here, I would like to say that AMD is becoming less helpful day
by day towards open source operating systems too, perhaps because
their serious errata lists are growing rapidly too).
-- All that's left of me, is slight insanity, whats on the right, I don't know. -- Bob Mould
All operating systems at the time quickly implemented a workaround for the bug.
Neither of the sources you give backs up that statement.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
ok it seems the wikipedia article has a link to the MS knowlagebase which says it was fixed for NT 4 (first by a hotfix and then rolled up into service pack 4) but not for windows 95. There is no information for more modern versions of windows there and the wikipedia article doesn't seem to link to any information on the status under linux.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
As if Apple would ever indicate their "house of cards" security is anything other than their propaganda has convinced people of.
Look at the MoAB: if it weren't for that, every Apple zealot and Slashdotter would still be trying to say Apple is the most secure OS in history. And people are STILL in denial about the MoAB!!!
Then, of course, there are the thousands of security researchers finding Apple 'sploits every day... which never get acknowledged or fixed.
But hey, Security through Obscurity has always been the secret behind Apple's security.
With the rate at which Intel-based Macs are failing after the latest 10.4.10 update I wouldn't be surprised if there was a processor update being slipped in quietly. And which may have gone terribly wrong for many users.
I also wouldn't be surprised if the problems were, in part, due to sloppy Q&A what with many Apple developers and testers being pulled into the iphone project...
In the free world the media isn't government run; the government is media run.
No, the problem with Parallels was CPU rendezvous.
They were incorrectly assuming that the CPU broadcast IPI would be handled synchronously, wwn they were hoisting up the OS and installing their hypervisor, so some CPUs would be running under it, and others would not. You can prove this to yourself by setting ncups=1 in the boot arguments (see the MacOS X kernel debugging tutorial on http://developer.apple.com/
According to their web site (if you read it), this was fixed in the last beta release.
-- Terry
Can you point to the release notes indicating the problem has been fixed? I can't seem to find them on the Parallels site. I'd really like to be able to use Parallels rather than a second laptop, but since I do actual work on my Mac, regular kernel panics are unacceptable.
I am TheRaven on Soylent News
This is from my correspondence from Microsoft. Sounds like a nifty BIOS update util. I found some more information about the Update.sys file. Please note that the update.sys loads any processor microcode update (that the BIOS should have installed) to the processors. If the BIOS is updated then it does nothing. It does what an up-to-date BIOS does. It checks to see if the microcode update it has within itself for the specific x86 processor stepping is newer than the one the BIOS has already loaded on the machine. If so, it will load the newer stepping and update the registry indicating that it has done so. Thus as new processors come on line and processor errata are discovered and fixed, we get new processor updates (Microcode) from Vendor which then need to be installed on the machine. These updates are included in any up-to-date BIOS for the machine. This is just a mechanism for Intel to get microcode updates installed on the various processors. By providing them the easier way, we ensure that the user gets the latest Microcode updates available and thus the machine runs more reliably. Like a service pack, each microcode update may contain fixes for any problems (erratum) found on the given Intel processor. Hence, instead of updating the BIOS from Floppy (the older way) we can do that from operating system and this update.sys loads any processor microcode update to the processors.