Fusion 7 is running VERY SLOW on the GM of Yosemite

[Stevamundo]

Basically Fusion 7 is unusable on the GM of Yosemite because fusion 7 is so slow.

When I was still on Mavericks 10.9.5  Fusion 7 was working just great. What happened?

Is anyway that i can fix this? Or do I have to wait for an update?

[lagirl55]

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

[AbortRetryFail]

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.

[mhawley5]

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

iMac (27-inch): AMD Radeon 6970M Video Card Replacement Program

Symptoms

Apple has determined that some AMD Radeon HD 6970M video cards used in 27-inch iMac computers with 3.1GHz quad-core Intel Core i5 or 3.4GHz quad-core Intel Core i7 processors may fail, causing the computer’s display to appear distorted, white or blue with vertical lines, or to turn black. iMac computers with affected video cards were sold between May 2011 and October 2012.

Resolution

If your iMac has an AMD Radeon HD 6970M video card and is exhibiting any of the issues described above, choose one of the following options to arrange to have your iMac evaluated:

• Apple Retail Store: Set up a Genius Bar appointment.
• Apple Authorized Service Provider: Find one here.
• Apple Technical Support: Contact us for local service options.

Before you go in for service, please back up your data. Learn more about backup options.If the iMac (27-inch) meets these requirements, Apple will replace the video card free of charge for four years after the first retail sale of the computer.

[BillT1901]

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.

[mhawley5]

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

Thanks,

M Hawley

[hmarktaylor]

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

[BillT1901]

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

[hmarktaylor]

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

[BillT1901]

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

[dariusd]

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

[caoslord]

Hello Darius,

I agree. I tryed both debug flag and reinstall of Yosemite on Yosemite, and all of them works.

After Yosemite reinstall it seem a little faster, but i am not sure.

I think it should be a upgrade procedure issue from previous OS....   but i am not gone deeper in both things.

Hint on debug=0xd4c, let' see what it is...

It is the sum of all the debug option and enable all debug option, this is the reason because it is very intrusive.

Bye Luca

[sn75]

My story (on late 2013 13" rMPB):

• upgraded to OSX Yosemite with Fusion 6 - worked fine except for rather annoying delay/flicker/extra click required when activating client window (Win 7)
• upgraded to Fusion 7, the minor delay/extra click required was gone (nice!), but the VM client was very unresponsive/slow when browsing file system and other minor tasks (ack! far far worse!)
• $ sudo nvram boot-args="debug=0x10"
• rebooted host

All seems to run fine now - thanks for the tip!

[dmes]

confirmed that putting the mac to sleep fixes the problem until the next reboot of the mac, no matter how many times  you launch/quit fusion or the vm.

The last time I tried this I didn't even bother shutting down the vm, just put the mac to sleep, waited for the disk to stop spinning, woke the mac and the vm resumed, and high utilization was gone, interrupts at normal.

[UnicomClint]

Worked for me - - annoying problem but due to you guys - - I am back working - - THANK TO ALL

[CuriosTiger]

Yep, I have one of those iMacs too: hw.model: iMac12,2. Here's a few more details that may or may not help:

I ran into an unrelated bug (presumably some cruft in my old Mavericks install) when I first upgraded to Yosemite. That bug caused installation to abort halfway through, leaving me an install that booted, but basically ignored my ~/Library. A subsequent clean install (which is what I'm still running) went perfectly. I did not use the Migration Assistant; instead, I manually restored just ~/stian/Documents and manually reinstalled my applications.

I used Fusion (7.0.1 Pro) in this configuration successfully until Saturday. On Sunday, I shut my iMac down, moved it to a different room, changed ONE thing in my settings (disabled Wifi as the new room has a wired Ethernet connection) and fired it back up. Windows 7 took almost 30 minutes to boot, and the sluggishness made the system completely unusable, just as others have reported.

Most other apps behaved normally. The system did feel a bit more sluggish than I'm used to even without Fusion running, but not drastically so. I've seen the temporary NVRAM register trick and will be attempting it in a bit. Reading the rest of the thread as well.

[CuriosTiger]

The debug=0x10 boot flag appears to have successfully worked around the problem for me. The interrupt storm also appears to be gone (I didn't grab a screenshot before rebooting, but it was in the 130,000-per-second range.) Now it looks much happier:

CPU 0:

        Vector 0x46(SMC): 0.20 interrupts/sec

        Vector 0x56(HDEF/EHC1): 67.59 interrupts/sec

        Vector 0x57(EHC2): 3.00 interrupts/sec

        Vector 0x73(GFX0): 531.74 interrupts/sec

        Vector 0x75(SATA): 3.40 interrupts/sec

        Vector 0x76(GIGE): 10.20 interrupts/sec

        Vector 0x7b(pci1b21,612): 4.60 interrupts/sec

        Vector 0x7c(pci1b21,612): 13.60 interrupts/sec

        Vector 0x7d(pci1b21,612): 8.40 interrupts/sec

        Vector 0xdd(TMR): 435.15 interrupts/sec

        Vector 0xde(IPI): 68.59 interrupts/sec

[HPReg]

Update from Apple:

"Engineering has determined that your bug report (18721746) is a duplicate of another issue (18200087) and will be closed."

[fayard]

Hi,

Just to add my experience on this problem.

- Hardware: MacBook Pro Retina 15 inch, late 2013

- Software: VMWare Fusion 7.0.1 / Windows 8.1

I have been experiencing some major slowdowns, enough to make the system almost unresponsive. Usually, it takes me 2 minutes of careful mouse clicks before I can shutdown the virtual machine. Once the shutdown command has been launched, everything is fast. I have tried the different fixes, and although some of them fix the problem temporarily, none of them really fix the problem:

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

- changed the virtual machine from version 11 to version 10

The best option I have so far is to pause the Virtual Machine, put the computer to sleep and then wake up my computer and resume my work on VMWare. Then it works fine until the next slowdown. It seems that the slowdown comes a lot when I use the Command Prompt. Once it is here, the only solution is to reboot or the sleep "trick",

[mhawley5]

Anyone know if this issue has been addressed in the 10.10.1 release?

Thanks,

mhawley

[MaciekP]

Anyone?

I think as rule we have to wait until VMWARE FUSION 7.0.2 and MAC OSX 10.10.2 for have it usable as a combo