Hello this is the real fix! (corrected, with a better suggestion)

open terminal.

Type: sudo nvram boot-args="debug=0x10"

press enter.

insert your password.

Reboot

Enjoy.

I fount in another post.

Here

fusion 6.04 with Yosemite GM very slow

It is not the real fix. Don't use

   sudo nvram boot-args="debug=0xd4e"

as it is way too intrusive. Instead, use

   sudo nvram boot-args="debug=0x10"

as recommended above.

Thank you,

please, what is the difference between the two option?

Best Regards,

Luca

See debug.h for the meaning of the various debug= bits. Search for DB_HALT on this page. Some bits are not documented, in that case download the xnu source code and grep for the bit.

Thank You!

Thank you, Nemo10904.

Although the "put the Mac to sleep" method was working for me, it seemed ridiculous that I would have to do that just to use the VM.

I took a look at the link you posted, then shut down my VM and re-installed Yosemite.

Result: No more problems.

Windows had been taking up to an hour to load; now it takes just a few seconds.

So far this fix is reproducible. I have rebooted several times and each time the VM and Windows work as they should.

I do not feel comfortable entering commands in Terminal and I imagine I'm not the only one.

So from all of us unskilled in the finer arts of computer programming (I just want to power the damned thing on and have it actually work), thank you for your post.

iMac12,1

Yes, I second that, lagirl55.

I reinstalled Yosemite on my iMac 14,2 last night.  I've been monitoring Fusion closely in Activity Monitor. 

No runaway CPU usage has shown up yet.  I'm keeping my fingers crossed.

iMac 12,2

After the symptoms started, I initially reinstalled Fusion 7 and then started a new install of Win 7.  It has been taking over a day to download the SP1 and updates.

I just applied the patch and it is working normally.  Just did another update and it took less than a  minute.  Thanks for the information on the patch.

Is this a permanent fix or will something need to be addressed by apple with Yosemite or by VMWare with fusion?

Also, from one of the earlier posts it sounded like this could be a hardware problem?  Did I understand that correctly.

Earlier I was having video issue with windows taking some time to refresh, and saw something on the apple site about the iMac 12,1 and 12,2 having video card issues, and in some cases the cards would need to be replaced.  Could this be related?

Thanks,

M Hawley

Mhawley. When you say "the patch," if you mean the nvram boot args flag, then yes, that's a temporary fix. It works, and that is good. But it appears to be that the problem is with Yosemite running on specific hardware (iMac 12,1 and 12,2). It's not really a Fusion problem at all...it's the fact that there is an interrupt storm going on on CPU 0 (where Fusion happens to live). Even if Fusion is not running on your machine (prior to setting the nvram boot-args flag, you could see the problem by running 'sudo powermetrics -s interrupts"...indicating CPU 0 is having real problems). It's not exactly a hardware problem either...it's something about the way Yosemite interacts with these specific model iMacs. Anyway, the solution will have to come from Apple in the form of a real patch.

For now, "ssudo nvram boot-args="debug=0x10"" will mask the problem. Hopefully, Apple will issue a fix soon. It's a pretty amazing regression in that anyone with one of these iMacs is going to be having the problem. Most just won't notice it, I guess, since they have 7 other CPUs that are healthy.

Thanks BillT1901 for the clarification.  And yes I was referring to the nvram boot args flag when I said "the patch".

Thanks,

M Hawley

I have a 12,2 iMac and the interrupts/sec were over 117000. After running the sudo nvram boot-args="debug=0xd4e" command and rebooting, the interrupts/sec are about 4 after logon to OS X and between 10.6 and 13 when running Fusion. The great performance on Fusion is back. Thanks for the information and solution.

h

hmarktaylor: it's been mentioned on other posts in this thread that the 0xd4e debug flag is way too intrusive. Use this instead:

    sudo nvram boot-args="debug=0x10"

Just run that and it will overwrite the one that you did.

Regards,

Bill

Thanks for taking time to correct me. I'm not sure what the command does or why it fixes this issue. What does it mean that the previous command is too intrusive compared to this one? If you would take time to give me some info it would be appreciated.

h

I'm not an expert, but from what I understand from reading the earlier posts by the VMWare staff, the issue (whatever it is) is masked by ANY non-zero nvram boot argument. The debug arguments are mostly support flags that generate helpful information from your computer in the form of log files, process info, etc., but you really don't know what they are doing. Anyway, that 0x10 flag has been described as "a silent no-op" argument, which I believe means it does nothing. So, since we don't really know what the other flags actually are doing, it's best to stick with the one that we know is safe.

btw...this issue is an Apple problem. I would expect a future patch will resolve the issue. An earlier post from VMWare indicated that they had raised the issue with Apple.

Regards,

Bill

Many thanks to Bill for those updates.

To expand on this: The debug options mostly modify the way your Mac will respond to some extreme events, such as a kernel panic – an OS crash, not an application crash.  Depending on the particular flags chosen, they might result in receiving a less-than-friendly and quite unhelpful message in the event of an OS crash.

debug=0x10 should have absolutely no effect on modern versions of OS X.  That it has any visible effect at all is quite a novelty in itself... I still have no firm idea why it makes this issue go away, but it seems to do so for many (but not all) affected users.  (Some of the folks who are not helped by debug=0x10 have reported success through re-downloading Yosemite and reinstalling it "in-place".  As with all mystery problems with as-yet-unknown causes, your mileage may certainly vary.)

Since debug=0x10 seems to have the same effect on this specific problem as debug=0xd4c does – while setting fewer of the debug flags – we have no reason to recommend debug=0xd4c and every reason to recommend the less-intrusive debug=0x10.

Thanks,

--

Darius