Virtual machines with ACPI enabled keep freezing temporarily on a MacBook => Fixed in SVN

[Sebastian Thürrschmidt]

I have a MacBook 4,1, running Ubuntu 8.10 Intrepid Ibex (amd64) and VirtualBox 2.1 (PUEL).

Guest machines with any operating system and ACPI enabled are practically unusable because, after running for some time, they will begin to freeze temporarily every few seconds. I can move the mouse pointer while the guest is in its frozen state, but otherwise everything comes to a standstill. No input is possible, and the display isn't being updated so that things like animated cursors or the hands of analog clocks won't move. When the guest becomes responsive again after a few seconds, it looks like it's trying to make good for the time lost by running faster for a few moments. Animated cursors, analog clocks etc. will run in an accelerated, jumpy way during this catch-up phase, which lasts for about two to four seconds. Shortly after that, the guest will freeze again, and so on and so forth. The host machine is not affected and remains responsive all the time.

This behavior becomes the more pronounced the longer the guest machine has been running. First there are only the slightest of delays, but within half an hour or so it becomes impossible to do anything inside the guest. Pausing and resuming, saving and restoring, or rebooting the guest, quitting and restarting VirtualBox or restarting the VirtualBox daemon make no difference at all. Only rebooting the host machine helps for a short while. Booting the host machine with the nohz=off option and/or inserting force_async_tsc=1 into /etc/init.d/vboxdrv, as suggested in the FAQ and in various forum posts, won't help. The only thing that helps is to disable ACPI for the guest in its advanced settings.

The problems began right after I upgraded Ubuntu from 8.04 to 8.10, initially with VirtualBox 2.0.2 (OSE), and they persisted as I switched to the PUEL version and updated it to the 2.0.4, 2.0.6 and 2.1 releases. Guest machines running Windows XP, Windows 2000, Ubuntu, as well as OpenSolaris are all affected. The freezes are more frequent and become longer earlier during a guest session on Windows guests than on Linux/Unix guests. This is in addition to the fact that existing Windows guests will most likely become inoperable when ACPI is disabled after installing the operating system.

A number of users, all of them using either Ubuntu or Archlinux on MacBook or MacBook Pro computers, have reported very similar problems in a forum thread started by me (​http://forums.virtualbox.org/viewtopic.php?t=11206).

The attached VBox.log file is from a Windows XP guest with ACPI enabled that I left running for about 15 hours with almost no interaction. It showed all of symptoms described here.

[Sebastian Thürrschmidt]

VBox.log file from a Windows XP guest with ACPI enabled left running for about 15 hours with almost no interaction.

[Tino Wu]

I confirm this. This happens exactly the same on my Macbook 2,1, too.

[Tino Wu]

Replying to Tinow:

I confirm this. This happens exactly the same on my Macbook 2,1, too.

And I run Ubunut 8.10 x86 edition.

[Frank Mehnert]

Please could you attach the output of dmesg (host of course) after you started a VBox sesson?

[Frank Mehnert]

Another question: Did 2.0.6 work for you or didn't you test it?

[Sebastian Thürrschmidt]

Output of dmesg right after resuming a Windows XP guest with ACPI enabled

[Sebastian Thürrschmidt]

See Attachments for host dmesg output. VirtualBox 2.0.6 had this issue too. Please let me know if I can do anything else to help.

[Frank Mehnert]

Ok. Please could you try the following: Make sure that all VMs are terminated. Then

rmmod vboxnetflt
rmmod vboxdrv
modprobe vboxdrv force_async_tsc=1
modprobe vboxnetflt

Then start a VM. Do the freezes still occur?

[Sebastian Thürrschmidt]

What do mean by "terminated"? Should I completely shut down the VM or is it okay to just resume it from a saved state?

[Frank Mehnert]

No need to completely shut down all VMs. Just make sure that no more VMs are currently running. Except the VM you are about to test now: But better shut down this VM properly. If that workaround should work, then you can check VMs with saved states as well.

[Sebastian Thürrschmidt]

Okay, I did this (i.e., entered sudo -i, then the commands you listed). Unfortunately it doesn't make any difference at all. It's still a very bumpy ride inside that VM. Do you want my log file and/or dmesg output for this too?

[Frank Mehnert]

Yes, please attach such a VBox.log file as well. And please attach the output of dmesg again (after you did that rmmod/modprobe as requested).

[Sebastian Thürrschmidt]

VBox.log after module reload

[Sebastian Thürrschmidt]

dmesg output after module reload

[Jose C Gomez]

I have this same problem Guest XP host Fedora 10 whenever I am running the VM it intermittently freezes. I seem to get a lot of errors on the log file. (Attached)

[Sebastian Thürrschmidt]

The bug is still there for me after updating VirtualBox to version 2.1.2.

[Sebastian Thürrschmidt]

Although the change log doesn't mention it, this bug appears to have been resolved in VirtualBox 2.1.4. Can anybody confirm this?

[Ketzal]

Running V2.1.4 since yesterday (including a couple of suspend/resume) without seeing the bug. Looks good so far. (MacBook 5,1 xVM 2.1.4 running XP guest on a Ubuntu 8.10 host)

[Sander van Leeuwen]

Thanks for the feedback.

[Ketzal]

BUG STILL HERE

After 23:30 running correctly, I hit the bug again : 23:31:02.434 ERROR [COM]: aRC=VBOX_E_IPRT_ERROR (0x80bb0005) aIID={fd443ec1-0006-4f5b-9282-d72760a66916} aComponent={Mouse} aText={Could not send the mouse event to the virtual mouse (VERR_PDM_NO_QUEUE_ITEMS)} aWarning=false, preserve=false 23:31:02.434 ERROR [COM]: aRC=VBOX_E_IPRT_ERROR (0x80bb0005) aIID={fd443ec1-0006-4f5b-9282-d72760a66916} aComponent={Mouse} aText={Could not send the mouse event to the virtual mouse (VERR_PDM_NO_QUEUE_ITEMS)} aWarning=false, preserve=false 23:31:02.506 ERROR [COM]: aRC=VBOX_E_IPRT_ERROR (0x80bb0005) aIID={fd443ec1-0006-4f5b-9282-d72760a66916} aComponent={Mouse} aText={Could not send the mouse event to the virtual mouse (VERR_PDM_NO_QUEUE_ITEMS)} aWarning=false, preserve=false

(MacBook? 5,1 xVM 2.1.4 running XP guest on a Ubuntu 8.10 host)

[ccarpinteri]

Hi, I can also confirm that the issue still remains in 2.1.4. I am running generation 1 MacBook Pro 15". I have a clean install of Mac OSX 10.5.6, fully patched. My guest is Windows XP SP3 fully patched. On top of the issues that have already been reported (intermittent freezing), at some point the host wireless card looses connectivity, and has to be disabled/enabled for it to come back. There definitely seems to be an issue surrounding networking.

For kicks, I tried to install a different network card (Intel Pro), but that didn't change anything. I have not tried to run the Windows XP virtual machine without a network adapter.

[Roger]

Issue still there in 2.2.0 BETA2 45227. Host: Debian sid, Guest: Moblin alpha 2

[ccarpinteri]

I can also confirm that the issue still exists in 2.20 BETA 2. The machine is unusable. Has the issue been acknowledged?

[Sebastian Thürrschmidt]

Strangely enough, for me the issue hasn't come back in VirtualBox 2.1.6 nor in 2.2.0 Beta 2, but it seems I've been just lucky. Some people still experiencing it means the issue should be given a thorough investigation as soon as one of the developers finds the time (and ideally, a MacBook).

[Ivo Smits]

I was just experiencing the same problem when I found this thread. It only affected my Windows XP VM, not the Vista one. Apparently VT-x/AMD-V had been disabled on the XP VM, but was still in use on the Vista VM.

After turning on VT-x/AMD-V on the XP VM the freezes seems to have gone away.

[Ivo Smits]

I've replied too soon. Apparently the freezes do continue, but are less noticeable. A reboot of the guest did (and does again) temporarily fix the problem. When I tried to save the VM state, it crashed (nothing interesting in the log file). The Vista 32bit VM has been running fine all the time.

[Sebastian Thürrschmidt]

So here we go again: The freezes have come back for me too after I installed Karmic Alpha 5 (fresh install) on my MacBook with the VirtualBox 3.0.4 .deb package (the one for Jaunty, as there doesn't seem to be one yet for Karmic).

It was the all too familiar pattern: Intermittent freezes in my Windows XP guest with ACPI enabled that were getting more and more noticeable during a session (not quite as bad as when I first reported the bug, but still bad enough to make the guest machine largely unuseable after an hour or so).

Since I really need that machine, I switched off ACPI, reassinged my hard disk images to IDE from SATA (because SATA without ACPI wouldn't work at all, making even Windows XP's setup hang with 100 % CPU utilization very early on), and did a repair install of Windows XP, which took extremely long due to several hangs and forced reboots. But it worked out just fine in the end, and with ACPI now disabled, the freezes are completely gone.

Before that, still in Jaunty, and with ACPI still enabled, my Windows XP VM had stopped functioning (hung shortly after booting) after updating VirtualBox from 3.0.2 to 3.0.4. I could fix that by downgrading to the earlier release, which worked fine in Jaunty by no longer in Karmic.

So it seems there are still quite a few issues left with VirtualBox on Macs under Linux, mostly related to ACPI. I'd be more than happy to provide any help I can in resolving these issues.

[Drew Frank]

I am also experiencing this issue. My hardware is a Macbook Pro 3,1.

Host OS: 64-bit Arch Linux

uname -a: Linux lappy 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 10:03:24 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

Virtualbox 3.0.8 PUEL running 64-bit Windows 7 with Guest Additions installed

Sample errors from my logfile:

00:16:19.470 ERROR [COM]: aRC=VBOX_E_IPRT_ERROR (0x80bb0005)
  aIID={fd443ec1-0006-4f5b-9282-d72760a66916} aComponent={Mouse} aText=
  {Could not send the mouse event to the virtual mouse (VERR_PDM_NO_QUEUE_ITEMS)}
  aWarning=false, preserve=false
00:20:25.215 TM: Giving up catch-up attempt at a 60 268 007 144 ns lag;
  new total: 183 021 939 910 ns

[Anders Olsson]

I have the exact same issue as described here

Host OS: MacBook Pro 5,3 - 64 bit Ubuntu 9.10

uname -a: Linux taupo 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linu

Host: VirtualBox PUEL 3.0.8 and 3.0.10

Guests: 64 bit Ubuntu 9.10, 32 bit Windows XP

All combinations of host and guest show the same behavior: ACPI enabled - guests starts freezing after some time. ACPI disabled - everything works.

[avelo]

Exactly the same behaviour with freezes Macbook2,1 Ubuntu 9.10 x86_64 (and also with 32) ViertualBox 3.0.12

[avelo]

Solved for me by recompiling the kernel with config HZ changed from 100 to 1000 No more freezes and VBOX_E_IPRT_ERROR errors

[Richard]

Can this be fixed in virtualbox? How do you recompile your kernel with config HZ changed from 100 to 1000? Why doesn't virtualbox warn that this is going to happen? I made 2 new vm's before I fugured it was a virtualbox issue...

[Anders Olsson]

How to recompile and configure your kernel should be described in the documentation of your OS/distribution. But the easiest workaround would be to just disable ACPI, that's what I did. If your guest is Windows then you probably need to reinstall it. Please report your host and guest OS to this ticket, the more information the more likely someone will actually fix this.

[Anders Olsson]

From the comments so far this seems to affect MacBook users independently of host OS (mac os, linux 32 and 64 bit) and guest OS (linux, windows...). It would be interesting to hear from anyone of the VirtualBox team, have you been able to reproduce it? Are all MacBook users affected? If so this would surely be a critical bug.

[Richard]

I can only vouch for linux (ubuntu specifically) host and windows guest on two macbook pro's one is a 13" one is 17" both in the 5,x generation.

[Anders Olsson]

That's very compelling evidence of that it affects all macbooks. It would be interesting to hear of any macbook owners that are not affected - if there are any. And also if the HZ change is a workaround that works for all cases, I must admit to being too lazy to try it out myself though...

[Richard Lobb]

Not much to add here except to say that I'm another frustrated macbook user with exactly the symptoms described above (2 sec hangups in the guest every 10 - 20 secs; streams of VERR_PDM_NO_QUEUE_ITEMS errors in the log).

My specifics: macbook Pro 3.1 (Intel Core 2 Duo T7500 @ 2.2 GHz, 3GB RAM); Host: Ubuntu 9.10; Guest: WinXP Pro SP3; VM-settings: have tried several, including VT-x on/off, nested paging on/off, different RAM sizes. Turning off ACPI after installing the Guest doesn't help.

I haven't yet tried a clean guest install with ACPI off as I have lots of extra apps installed. But it's sounding like I'll just have to take a deep breath and do it.

FWIW I originally created the VM on a desktop (where it worked fine) and ported it across to the macbook.

[Peter Arrenbrecht]

Same here. MacBookPro4,1 Karmic 64bit host, WinXP guest.

[Frank Mehnert]

Please attach a VBox.log file of a VBox 3.1.4 session to this ticket.

[Richard Lobb]

Replying to trampgeek:

Not much to add here except to say that I'm another frustrated macbook user with exactly the symptoms described above (2 sec hangups in the guest every 10 - 20 secs; streams of VERR_PDM_NO_QUEUE_ITEMS errors in the log).

My specifics: macbook Pro 3.1 (Intel Core 2 Duo T7500 @ 2.2 GHz, 3GB RAM); Host: Ubuntu 9.10; Guest: WinXP Pro SP3; VM-settings: have tried several, including VT-x on/off, nested paging on/off, different RAM sizes. Turning off ACPI after installing the Guest doesn't help.

I haven't yet tried a clean guest install with ACPI off as I have lots of extra apps installed. But it's sounding like I'll just have to take a deep breath and do it.

FWIW I originally created the VM on a desktop (where it worked fine) and ported it across to the macbook.

Firstly: a clarification. When I said turning off ACPI after installing the Guest didn't help, I meant turning off IO ACPI. Completely turning off ACPI with VBoxManage just crashes the guest as many people have pointed out.

Secondly: I tried installing WinXP SP2 from DVD onto a brand new VM after turning off ACPI with VBoxManage and it hung some distance into the install, after the restart. I tried four times and it always hung at exactly the same point. Win 7 totally refuses to install on a non-ACPI machine.

Thirdly: the good news. My problems are solved! Well mostly, anyway. I used Avelo's suggestion and rebuilt the Ubuntu 9.10 kernel with config_HZ set to 1000 (it was 250 before the change, I think). As he reported, the intermittent hangs and all the log file error messages have completely ceased. I've been working happily with this system for several days now. I feel that it's occasionally a little bit more sluggish than on my desktop but still completely comfortable to use, whereas before it was intensely frustrating. The only oddity is that very occasionally (perhaps every hour or so but I haven't really been observing) the guest seems to hang for quite a few seconds with the Ubuntu monitor showing VirtualBox on 100% CPU usage. There are no error messages logged, though. This may even just be pure WinXP behaviour -- I seem to remember it doing that on my Macbook occasionally when running native on BootCamp.

Rebuilding the kernel was a longish process, taking several hours of download and then several hours of compilation. However, it took very little of my own time and was much more straightforward than I'd expected. I followed the detailed step by step instructions at ​http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/ exactly. At the point where the instructions say "Make your changes, save the configuration and then keep going until the script ends" you just have to find the HZ setting (under the category "Processor settings" or some such) and change it to 1000.

So heartfelt thanks Avelo for the suggestion (and Peter in Ubuntu for the instructions on compiling Ubuntu Karmic). My life has improved enormously :-) Longer term, though, it would be nice to have a fix that allowed me to update my kernel whenever a new version comes out without having to do a recompile.

[Richard Lobb]

VBox log for 3.1.4 as requested by Frank 10/3/2010. [Booted the generic Ubuntu kernel not my 1000 Hz patched job]. Ran VM until problems started (takes a few minutes).

[Richard Lobb]

Replying to frank:

Please attach a VBox.log file of a VBox 3.1.4 session to this ticket.

Done.

[Anders Olsson]

VBox.log from 3.1.4, host and guest Ubuntu Karmic 64 bit, ACPI enabled

[Frank Mehnert]

Hmm, could you please test the following:

time cat /proc/acpi/ac_adapter/*/* > ~/log
time cat /proc/acpi/battery/*/* >> ~/log

and attach the resulting file ~/log to this ticket? Thank you!

[Anders Olsson]

Contents of /proc/acpi/ac_adapter/*/* and /proc/acpi/battery/*/* for MacBookPro5,3

[Frank Mehnert]

andeol, thank you but I was more interested in the output of the time command. My fault. Could you execute these two commands again and post the output of time for each of these commands?

[Anders Olsson]

Here goes:

$ time cat /proc/acpi/ac_adapter/*/* > ~/log

real	0m0.054s
user	0m0.000s
sys	0m0.000s

$ time cat /proc/acpi/battery/*/* >> ~/log

real	0m9.880s
user	0m0.000s
sys	0m0.000s

[Frank Mehnert]

Yes, that is it! It takes 10 seconds on your host. These 10 seconds are the reason for the guest delays and I assume this is the same with the other hosts! I will check if we can workaround that problem ...

[Peter Arrenbrecht]

$ time cat /proc/acpi/battery/*/* >> ~/log real 0m2.801s user 0m0.000s sys 0m0.010s

MacBookPro4,1 Karmic 64-bit with kernel from ppa Linux sapient 2.6.32-02063209-generic #02063209 SMP Wed Feb 24 10:09:53 UTC 2010 x86_64 GNU/Linux

[Frank Mehnert]

Yes, same problem. 2.8 seconds are much too long (on a "normal" Linux host this should take less than 5 milliseconds).

[Sebastian Thürrschmidt]

I get a whopping 15 seconds plus on my non-Pro MacBook 4,1 for cat /proc/acpi/battery/*/*. Good to know that finally the reason for this bug seems to have been found. Could this affect other applications too? If this is indeed a kernel bug, maybe it shoud reported on bugzilla.kernel.org.

[RicoPuerto]

This does not only affect MacBooks - I'm having the same problem on a Dell Vostro 1510. Anyhow, I disabled the Battery device in the Windows XP guest and this seems to fix it.

[SwedishWings]

I can confirm that disabling all devices under Battery in Device manager solves the problem on my MacBookPro5,1 w/ Ubuntu Karmic Host and WinXP guest in VirtualBox 3.1.4. Not tested under OS X yet.

Thanks RicoPuerto for the suggestion, i can finally work with my WinXP again!

/Mike

[spbrereton]

Replying to Tinow:

Replying to Tinow:

I confirm this. This happens exactly the same on my Macbook 2,1, too.

And I run Ubunut 8.10 x86 edition.

I was asked to take a look at this ticket after I opened ​http://www.virtualbox.org/ticket/5521 - however, I asserted that I'd not experienced it. Of course as soon as I said that, I did notice some symptoms, but nothing like as severe as the original poster. The only thing different was that I was on a Wifi connection, and normally, I'm on a LAN connection. As soon as I went back to a LAN connection, the problem eased (but didn't disappear until a reboot).

Running 9.10 PAE (upgraded from 9.04) Running VirtualBox 3.1.4 r57640 (upgraded from about 3.0.2 iirc)

[Frank Mehnert]

This problem (Accessing /proc/acpi takes ages on some Linux hosts) will be fixed with the next maintenance release.

[Sebastian Thürrschmidt]

Frank, thanks a lot for finally having a closer look into this! I'm eagerly awaiting the next maintenance release.

Diabling the battery device in Windows XP (hilariously called "ACPI-konforme Kontrollmethodenbatterie" in my localized version), as suggested by SwedishWings, did indeed make my old ACPI-enabled VM usable again. The intermittent freezes have disappeared completely.

Booting the VM, however, takes rather long, with the process stalling two or three times in the early initialisation phases of the OS. Related entries in the vbox log file look like this:

00:06:32.846 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007f86918cb000 w=640 h=480 bpp=0 cbLine=0x140
00:07:42.281 TM: Giving up catch-up attempt at a 68 063 501 193 ns lag; new total: 1 067 265 072 955 ns

This may or may not be related to the Linux battery issue. The next version of VirtualBox will certainly help to clarify this, hopefully by eliminating these delays.

[Richard Lobb]

Many thanks indeed, Frank.

[Richard]

YAY

[Frank Mehnert]

thuerrschmidt, the issue with Giving up catch-up attempt at ... could be related to #6250. I've posted a solution there as well. Another workaround for the ACPI problem (if you can't wait for the next release) would be to recompile the host kernel and to disable CONFIG_ACPI_PROCFS_POWER which hides the entries in /proc/acpi/battery and /proc/acpi/ac_adapter. The next release will contain a proper fix for accessing these directories and it will access the new /sys directory as well but for now hiding these directories from VirtualBox would help as well.

[Sebastian Thürrschmidt]

Sorry, but the mod_timer_pinned() won't help. I adapted both copies of timer-r0drv-linux.c that I found on my machine, in /usr/share/virtualbox/src/vboxdrv/r0drv/linux/ and in /var/lib/dkms/vboxdrv/3.1.4/build/r0drv/linux/, and recompiled the kernel modules. Booting still takes unusually long with delays totalling an estimated two minutes around the time when the Windows logo starts to appear. I can live with that for now, it's slightly annoying but not as crippling as those freezes. If the delays don't go away in the next VirtuaBox release, I guess I'll just file a new bug report.

Until then the battery workaround is fine for me. I don't think I'll go into rolling my own kernels just for that.

[JT]

SOLVED

Before:

# time cat /proc/acpi/battery/*/*

real 0m18.987s user 0m0.000s sys 0m0.020s

Reference: ​http://bugzilla.kernel.org/show_bug.cgi?id=8246

Change:

# diff /etc/grub.d/10_linux /etc/grub.d/10_linux.ORIG 71c71 < linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} acpi=rsdp_forced ro $2 ---

linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro $2

# update-grub

# reboot

After: # time cat /proc/acpi/battery/*/*

real 0m0.068s user 0m0.000s sys 0m0.010s

Now VirtualBox Guest is well behaved.

[JT]

SOLVED

(2nd try with additional details and hopefully fixing the wiki formatting problem)

Host: 

  # sudo dmidecode -s system-product-name
  MacBookPro5,2

  # cat /etc/lsb-release 
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=9.10
  DISTRIB_CODENAME=karmic
  DISTRIB_DESCRIPTION="Ubuntu 9.10"

  # uname -a
  Linux mac 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:02:26 UTC 2010 x86_64 GNU/Linux

  VirtualBox 3.1.4

Guest:
  Microsoft Windows XP Service Pack 3

Before:

  # time cat /proc/acpi/battery/*/*

  real 0m18.987s 
  user 0m0.000s 
  sys 0m0.020s

Reference: 
  http://bugzilla.kernel.org/show_bug.cgi?id=8246 

Change: 

  # diff /etc/grub.d/10_linux /etc/grub.d/__10_linux.ORIG
  71c71
  <     linux    ${rel_dirname}/${basename} root=${linux_root_device_thisversion} acpi=rsdp_forced ro $2
  ---
  >     linux    ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro $2

  # update-grub

  # reboot


After:

  # time cat /proc/acpi/battery/*/*

  real    0m0.068s
  user    0m0.000s
  sys    0m0.010s

Now VirtualBox Guest is well behaved. 

[JT]

Darn, VirtualBox was fine until I posted the "solved" message, and then it mocks me by falling back into the unusable behavior.

root@mac:~# time cat /proc/acpi/battery/*/*

real 0m33.552s user 0m0.000s sys 0m0.090s

[Frank Mehnert]

Fixed in 3.1.6.

[RicoPuerto]

This is OK now, thank you very much! Rico

[Sebastian Thürrschmidt]

Thank you very much! The freezes have indeed gone after the update. Also gone are the delays while booting the Windows guest.

When I tried (repeatedly) to re-enable the ACPI battery device in the Windows guest, the VM froze with very high CPU utilization on the host. In the end I removed the battery device altogether, rebooted the guest, and voilà, there it was again, enabled and fully functioning. (I don't really need it, I just wanted to make sure that the bug fix is effective.)

[Frank Mehnert]

Guys, thanks for the feedback!

[JT]

Thanks Frank, Confirmed fix in VirtualBox 3.1.6.