Separate names with a comma.
Discussion in 'Windows Guest OS Discussion' started by Markcub, Aug 21, 2014.
@Michael_Heinsohn thanks for the link
I have implemented the 'terminal script fix' as suggested. There's certainly been a huge improvement. More or less back to normal. Now if it will just stay that way after a full reboot then that will be marvellous and the person who wrote the script deserves our eternal thanks.
The instructions at this link http://forum.parallels.com/threads/parallels-10-running-slow-on-yosemite.326205/ fixed the issue for me as well. All Guest OS's are no as responsive as before. Thank you @Michael_Heinsohn.
Just to add to the data: My Yosemite OS 10.1 and PD 10.0 where working beautifully. After updated PD to 10.1 I got the same chugging slow-down as everyone has described here. The only other thing weird I did was change the Yosemite language setting to fix MS Lync per this link.
I followed the link referenced by Kiran_K_Ayyalasomayajula, I read that amongst the other items, the PD10 seemed to be having problems with CPU's. My system, which was having problems, was configured to use 4 CPU's. The referenced article suggests adding a "DEBUG" parameter to the startup of your system. Instead of trying this I simply reduced my CPU's to 1. I now have a fully functional VM running with pre-yosemite speeds. This includes after reboots. Why this works is unknown to me however I am not complaining. I am running a iMAC 2011 (early model) with 32GB of ram and a mixture of SSD and hard drives. I can now display my windows start screen with zero "delay". Instead of 40-90 seconds it is immediate.
While I would prefer to use more CPU's, if one works, who am I to argue with success. Hopefully this helps someone. Again, I made no alterations beyond Yosemite (retail final release) which is running a fresh copy of PD10.1 (28600) which according to Parallels is the "latest".
Could you please provide us with the following information:
1. Follow the KB http://kb.parallels.com/en/117114 from step 1 to step 6. Save the terminal output to a file "trace_intr_VMrunning" on the Desktop
2. Generate the Problem Report when the issue is reproduced (when you can see the CPU level of the VM at 99% or more). Save the PR number.
3. Stop the VM and run the trace_intr utility one more time as per KB 117114 (steps 3-6). Save the terminal output to a file "trace_intr_VMnot_running" on the Desktop
4. Reboot the Mac, do not launch PD10. Run the trace_intr utility (steps 3-6). Save the terminal output to a file "trace_intr_PDnot_running" on the Desktop
5. Send the PR number and the 3 files to us.
I have my three files as described above. However, I don't understand number 2 above. What's the Problem Report? Where would I find the Problem Report number?
Alright, got the report number and the files. It's attached.
Apparently there's a workaround that's posted in this this thread. I am basically dead in the water currently. Can I use that solution (NVRAM) for now while this is being looked into?
Thank you for your help!
Thank you, Martin!
I am afraid you forgot to attach the Problem Report number.
To generate the Problem Report:
- Start the VM
- Make sure the CPU usage jumps above 100%
- While the VM is on the screen and in focus, go to the Parallels || menu (close to time-date, WiFi, battery, etc) -> Report a Problem, wait till it is generated
- Click Send then copy the PR number and post it here
btw. Do I get it right, trace_intr does not report any "interrupt storm" with the com.apple.driver.AppleACPIPlatform driver right after the Mac reboot when PD10 is not launched yet?
The name of the zip is the PR number that was generated when the CPU was high.
As for your last comment, I am not following you. I don't know what that means.
OK, I am sorry!
As for my last comment:
the com.apple.driver.AppleACPIPlatform driver shows pure zeroes when PD is not running (trace_intr_PDnot_running file)
so, if the file was generated right after your Mac is rebooted and PD was not launched yet, it means it is a bit different situation than I, for example, have on my test iMac.
Anyway, than you very much for your help! I am going to add this information to our current investigation.
Since this was unexpected, I took another output. I checked my file that I posted and yes the values are 0. I ran it again. Waited a little while longer for the machine to settle down and then ran the trace. Attached the file. And the numbers are not all zeros now.
Sorry for the false negative.
Thanks for the prompt responses!!!
Great, thank you!
Had the same issue. Mavericks + PD10.1.0 (28600) and absolutely no issues. Upgrade to Yosemite (free when released) and Win7 Guest started stuttering, and generally un-usable. The interesting thing is that it wasn't that way on my MBP, only on my iMac.
I created a Yosemite Boot USB from here: http://osxdaily.com/2014/10/16/make-os-x-yosemite-boot-install-drive/ with the intention of possibly having to do a clean install. However, I ran the installer to re-install Yosemite over my upgrade. Once completed, all Guest VM's back to normal. No more single core hogging, no stuttering, no waiting 5 minutes for apps to open in windows.
It's a little more tedious than the Terminal script, but if that doesn't work, probably the next best effort.
There is some insight coming from the VMware forum (This problem is affecting all VM software) :
Maybe this can help the folks at Parallels and if this is a problem in the Yosemite kernel, put some pressure at Apple to come with a solution.
@Anderson_Santos Thanks for the link and additional background. Based on my brief discussion with @SergeyL they are aware of the interrupt storm and that was one of their first pieces of information items they spoke about. So I believe we are on the same page. The problem is no one really knows what the turnaround time for this will be. Will Apple fix this? Will Parallels (and VMWare) issue an official patch/workaround?
@SergeyL I am happy to be the guinea pig for another day (run more traces/logs) but I am not sure how much longer I can be without my Windows VM. If there are any suggestions of what I should do in the meantime, please let me (us) know. Otherwise I am going to have to try one of the suggested solutions above.
I used the command :
sudo nvram boot-args="debug=0x10" and rebooted.
This solved my problem. Now Parallels and my Windows 8.1 VM are running without any slow down. I have a IMac 12,1.
Before I try the debug+0x10 trick I used the trace_int to create the three files as requested.
The PR number is: 52160986
The three files are zipped as one was over 1 meg and the forum would not allow me to upload it??
Well I just did the fix and things do seem to be much better but the %CPU is still running quite high at times although it is running in the single digits when nothing is happening which is certainly much better. Opening Firefox caused CPU usage to go up to 60 and playing a CNN video caused it to jump up to 167 but then it averaged around 100 after that. Energy impact is very high at around 120.
They still need a proper fix but this is a start!