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?
hw.model: iMac12,2
hw.model: iMac12,2
iMac12,1
Everything works fine if I put the iMac to sleep.
iMac12,2
hw.model: iMac12,2
Any idea when a fix will be available? (One that doesn't require me to mess with NVRAM settings I don't understand, and am consequently hesitant to try...)
Edit: Having tried the sleep trick, that appears to be a good interim stop-gap measure.
hw.model: iMac12,2
Thanks!
Bob
Here is the result of our early investigation:
1) The root cause of the issue is a storm of interrupt 0x49 (apparently ACPI events, we are not sure yet) on CPU 0.
You can verify this by running the following command in Terminal:
sudo powermetrics -s interrupts
On the machine which I'm currently observing (remotely, using Screen Sharing), the command yields:
CPU 0:
Vector 0x49(iMac12,2): 105725.77 interrupts/sec
This rate of interrupts (more than one interrupt per microsecond!) is way too high.
2) The issue occurs regardless of whether Fusion (or a VM) runs or not. There is something seriously wrong on the machine. Fusion is just the messenger of the bad news.
3) The issue is a software regression in OS X. It does not happen when the host OS is Mavericks, it does happen when the host OS is Yosemite.
4) The issue only happens on specific hardware. So far we have identified iMac12,1 and iMac12,2 models. There might be others. But what is certain is that not all Macs are affected, or we would have found the issue much sooner.
5) Adding debug=<any non-zero value> to boot-args (using the nvram command) and restarting the host OS appears to suppress the issue. We do not know why at this point. The source code for the Yosemite kernel has not been released yet and the AppleACPIPlatformExpert class comes in the form of a binary-only kernel extension, which complicates further investigation. Nevertheless, the DB_KDB bit (value 0x10) has been a silent no-op in Mountain Lion and Mavericks, and it is likely a silent no-op in Yosemite as well. So for now, to workaround the issue, we recommend you add debug=0x10 to boot-args (using the nvram command) and restart the host OS.
6) Some forum users have reported that manually putting the Mac to sleep appears to suppress the issue as well.
7) VMware is about to file a Radar bug with Apple about this issue.
iMac 12,2 Here
> 7) VMware is about to file a Radar bug with Apple about this issue.
rdar://problem/18721746 filed with Apple.
I have an iMac12,1 and am seeing the slow Fusion performance and also getting the 0x49 interrupt storm on CPU 0
I did a re-install and it fixed it no need to add any more ram or cores here.
Thank you for the early investigation results.
The workaround "Putting the Mac to sleep" has worked out for me as well. (That saved my day, THANK YOU wickedstealthy!)
Yesterday I fixed the performance issue with a verify disk run on my hdd with disk utility. Today this task doesn't work out.
KR
Marcus
My config:
Yosemite and VMWARE Fusion
Model Identifier: iMac12,2
Processor Name: Intel Core i7
Processor Speed: 3,4 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 8 MB
Memory: 16 GB
On point 6)
It seems very repeatable on my iMac. I removed the debug and checked what happend with the interrupt rate.
Before putting the iMac to sleep when starting the VM it is in the same magnitude as you mentioned. As soon as I put it to sleep and wake it up. The interrupt rate on CPU0 drops to a normal level.
Fusion is definitely running much slower on my late 2013 MBP after installing Yosemite (clean format and install of Yosemite, not an upgrade). No changes to the VM guest - just the host OS (previously Mavericks).
I didn't see my hardware listed in any of the previous posts. The terminal command for my machine yields the following:
hw.model: MacBookPro11,1
Same here,
iMac 12.1
Manually sleeping iMac and VMware work greet with all my VM, Mavericks, Windows 7, Windows 10 and I make a new one, VM Yosemite.
Thank you very much for the tip.
hw.model: iMac12,2
hw.model: iMac12,2
Just wanting to clarify the "slow" behaviour here, is it the VMWare Fusion app itself, or guests being run?
I have a MacBookPro11,3 (late 2013 MBPr). Running Yosemite as a guest in VMWare is like trying to wade through a pool of cold treacle (2 Core's provided, 2GB of RAM). This problem doesn't exist with Mavericks guests running same configurations.
Just wanted to say thanks, the nvram param worked a treat! I can work again
> Just wanting to clarify the "slow" behaviour here, is it the VMWare Fusion app itself, or guests being run?
In this forum thread, we are discussing the slowness of all VMs (any guest OS) on Yosemite host OS on mid-2011 iMac models.
It is caused by an Apple bug in Yosemite, which creates an interrupt storm on CPU 0, which slows down CPU 0.
It negatively impacts all hypervisor products, VMware Fusion included.
> I have a MacBookPro11,3 (late 2013 MBPr). Running Yosemite as a guest in VMWare is like trying to wade through a pool of cold treacle (2 Core's provided, 2GB of RAM). This problem doesn't exist with Mavericks guests running same configurations.
That is a different issue than the one being discussed in this forum thread. In the issue you describe, the VM runs a Yosemite guest at normal speed, except for mouse input: the mouse cursor in the guest lags behind mouse moves. This is particularly visible when browsing menus up and down, or moving windows around.
We have filed it with Apple as rdar://problem/18104412 "VMWARE: Non-deterministic and erratic mouse cursor behavior in Yosemite as a guest OS".
It negatively impacts all hypervisor products, VMware Fusion included.