Guest OSes Slow - Sleep workaround...

Z

Zenkimoto

Junior Member
I have multiple guest OSes installed (Windows XP, Mac OS X, etc) and when I start either one of them, it is incredibly slow. I can barely do anything and it appears the CPU is churning. However, when I put my host system (Mountain Lion) to sleep, and go wake it up, it goes back to normal.

This started happening after the last parallels update. I've read on the forums that the "sleep" is a work around. The other thing to do was to reinstall Parallels Desktop 8, which I did. It seemed to work the first few times and now it's back to the same. It's quite annoying to have to put my computer to sleep and wake it up in order use my guest OSes.

Anyone experience this issue and know how to solve this or is this a Parallels bug?
 
Hi Zenkimoto,

Could you please provide us with two report IDs:
1. First report we need is when you just start your VM and observe system running slow;
2. Second report is right after you put your Mac to sleep & wake it up

Here is how you can submit the problem report (post the IDs here please): http://kb.parallels.com/9058
 
Thank you Andrew. Here are the report IDs for before and after putting the Host OS (Mountain Lion) to sleep:

Guest OS (Mountain Lion):
Before: 20959267
After: 20959309

Guest OS (Windows XP)
Before: 20961780
After: 20961819

As I stated, after I wake up the host OS, performance of the guest OS goes back to normal. At first I thought it was a guest OS specific issue, but since it happens on both Mac and Windows guest OSes, it doesn't appear so.
 
Same issue here. Each time I restarted the guest OS (Windows XP), it is soooo slow. But if I restarted the host OS (Mountain Lion) even while the guest OS is starting, the performance of the guest OS goes back to normal.
 
Hello Andrew,

Should I put in a support request?

Here are two other report IDs:

Before putting Host OS to sleep: 21008398

After waking up Host OS: 21008515
 
Marquee said:
Same issue here. Each time I restarted the guest OS (Windows XP), it is soooo slow. But if I restarted the host OS (Mountain Lion) even while the guest OS is starting, the performance of the guest OS goes back to normal.
Click to expand...

Hi Marquee,

Can I have two problem report IDs from you please? Same as above.
 
Zenkimoto said:
Guest OS (Mountain Lion):
Before: 20959267
After: 20959309

Guest OS (Windows XP)
Before: 20961780
After: 20961819
Click to expand...

Zenkimoto,

from these problem reports I can see that you are experiencing interrupt storm (e.g. your hardware sends a lot of interrupt requests to CPU) that disappears after sleep/wakeup sequence.

To help us understand the problem more clearly please do the following:

1) Download trace_intr tool from here: http://fe.parallels.com/6e3d0c6947b40d146b8cf02c03069173/trace_intr
2) Make it executable (in Terminal.app):
$ chmod +x ~/Downloads/trace_intr

3) Make sure Parallels Desktop is not running and start the tool as following:
$ sudo ~/Downloads/trace_intr 1 > ~/Downloads/before_wo_pd.log

Type your user's password. Wait for ~30sec and type Ctrl-C to stop the tool

4) Launch Parallels Desktop but do not start guest OS. Start the tool again:
$ sudo ~/Downloads/trace_intr 1 > ~/Downloads/before_with_pd.log

Wait for ~30sec and type Ctrl-C to stop the tool

5) Start guest OS and launch the tool again:
$ sudo ~/Downloads/trace_intr 1 > ~/Downloads/before_with_guest.log

Wait for ~30sec and type Ctrl-C to stop the tool

6) Put your Mac to sleep, wake it up and launch the tool again:
$ sudo ~/Downloads/trace_intr 1 > ~/Downloads/after_with_guest.log

Wait for ~30sec and type Ctrl-C to stop the tool

You should have 4 log files in your Downloads folder at this point (before_wo_pd.log, before_with_pd.log, before_with_guest.log, after_with_guest.log). Please attach them to this thread.

Thank you for your help!
 
@pborzenkov

I apologize that I did not see this response. It has been two months now... I just tried the link for the trace_intr tool but it doesn't seem to work. Can I get another link so I can diagnose the issue? I'm still putting my Macbook Pro every time I use parallels and it's getting pretty annoying at this point.

Thanks for your help!!!
 
@pborzenkov

I seem to be having problems with the forum attachments. Every time I click on the "Manage Attachments" button, it gives me a blank screen (even on different browsers). Anyways, I have uploaded my Log files onto my server here: http://www.zenkimoto.com/Logs.zip

If you guys get the forum fixed, I will upload my files here.

Thanks!

zenkimoto
 
Hi Zenkimoto,

thanks for the logs.

From these logs I can see that you have *a lot* of interrupt requests (about 550000 per second) on interrupt vector 52 even when Parallels Desktop is not running.
This vector is shared between USB and SATA devices. We have already seen such problems with MacBook Pro 5,1 or 5,2 when CD-ROM was changed to SSD drive.
From your original problem report I see that you did the same.

This problem is not caused by Parallels Desktop software, but due to specifics of virtual machines functionality, those interrupt requests cost a lot more CPU time when
virtual machine is running. That is why when VM is not running, you barely see the overhead of this interrupt storm, but when you start it, the CPU usage goes through the roof.

You could try the following workaround from Parallels Desktop side: add 'vm.vcpu0bind=1' flag to boot flags of your VM: (Virtual Machine -> Configure -> Hardware -> Boot Order). This will bind virtual CPU0 to real CPU1. MacOS X processes interrupt requests on CPU0, so this flag should lower the CPU usage because VM will not deal with interrupt requests from hardware.

Please post the results here.

Thanks,
Pavel
 
Hi Pavel,

Thank you so much for your help. You are absolutely correct. I replaced my DVD-ROM drive with another hard drive. I did not realize that this would cause interrupt problems.

I have tried your workaround, however it crashes my system and gives me the "gray screen of death" kernel panic before it reboots. I don't think I will be doing that anymore.

Anyways, I think I'll just resort to the putting my machine to sleep. It will have to do for now. Thank you very much for finding what the issue is. Unfortunately, I don't think I will be putting the DVD-ROM back in anytime soon.

Thanks again,

Zenkimoto
 
Sorry to dig up an old thread, but I seem to have a similar problem and wanted to check if I have the same situation. I see that the trace_intr tool link expired after 30 days. Do you think you could post a new link? Thanks in advance!
 
Thank you very much for the quick response! It seems that my CPU0 is hammered (500000) by the com.apple.driver.AppleAHCIPort after a sleep/wake cycle (regardless of Parallels). The OS is on an SSD. Maybe this is the reason? Anyway, the rest of the machine runs fine (a little slow on the GUI side though) but Parallels really comes to a crawl after the sleep. It seems the following boot flag actually works:

vm.vcpu0bind=1, vm.vcpu1bind=2

Also just out of curiosity, any ideas why this happens in the first place?
 
Last edited:
skulaksiz said:
Thank you very much for the quick response! It seems that my CPU0 is hammered (500000) by the com.apple.driver.AppleAHCIPort after a sleep/wake cycle (regardless of Parallels). The OS is on an SSD. Maybe this is the reason? Anyway, the rest of the machine runs fine (a little slow on the GUI side though) but Parallels really comes to a crawl after the sleep.
Click to expand...

As I said before, this is the overhead of virtualization. Each interrupt request costs a lot more CPU time when VM is running. Normally, there are several thousands of these requests per second so you don't notice them. But when there are hundreds of thousands of these requests the CPU spends all the time dealing with them.

skulaksiz said:
Is there any way I can set the "affinity" of parallels to the second and third cores somehow? i.e. Will this following work?

vm.vcpu0bind=1 vm.vcpu1bind=2
Click to expand...
It depends on which version of MacOS X you are using. If 10.8, then, unfortunately, the answer is no. Due to the changes in OS X kernel we can't bind VCPUs to physical CPUs anymore.

If you are using 10.6 or 10.7, then yes, you can. Add these flags to boot flags of your VM (each on separate line):
vm.vcpu0bind=1
vm.vcpu1bind=2

skulaksiz said:
Also just out of curiosity, any ideas why this happens in the first place?
Click to expand...

We investigated the problem with MacBookPro 5,1 and 5,2 and it looks like a bug in OS X drivers.
The problematic interrupt vector is shared between AHCI (SATA) and USB devices. And whether the problem occurs or not
depends on the order in which these drivers were loaded. That's why sleep/resume cycle helps sometimes (drivers could be re-loaded in different order).
 
Interrupt storm workaround

pborzenkov said:
As I said before, this is the overhead of virtualization. Each interrupt request costs a lot more CPU time when VM is running. Normally, there are several thousands of these requests per second so you don't notice them. But when there are hundreds of thousands of these requests the CPU spends all the time dealing with them.


It depends on which version of MacOS X you are using. If 10.8, then, unfortunately, the answer is no. Due to the changes in OS X kernel we can't bind VCPUs to physical CPUs anymore.

If you are using 10.6 or 10.7, then yes, you can. Add these flags to boot flags of your VM (each on separate line):
vm.vcpu0bind=1
vm.vcpu1bind=2



We investigated the problem with MacBookPro 5,1 and 5,2 and it looks like a bug in OS X drivers.
The problematic interrupt vector is shared between AHCI (SATA) and USB devices. And whether the problem occurs or not
depends on the order in which these drivers were loaded. That's why sleep/resume cycle helps sometimes (drivers could be re-loaded in different order).
Click to expand...

Just to help you with a workaround I'm using to avoid this problem: simply reboot you Mac resetting NVRAM (alt-cmd-PR). It works ever. You can use it every time you shut off the Mac; if you leave it in standby the storm does not appear.

I also opened an issue with Apple, but they answer that this problem arise due to a unsupported HW config. They will not investigate about this bug; I'm quite sure that it's a bug with MacBook Pro releases 5,1 - 5,4. A friend of mine has a new MBPro with same HW config and this issue does not appear.
 
You must log in or register to reply here.
Back
Top