virtualbox.org

Welcome back from exile, Socratis and thanks to erdeslawe for this very good new


So my problem is probably more related to OS X hosts specific (specially to Mac Book Pro 13"/Intel HD 4000 GPU ?) than Linux guests, no ?
Shouldn't the thread be moved again there ?

Sure I can move the thread, if it makes you feel better . One thing that I realized that I haven't seen so far is a VBox.log.zip:

• Follow a "start the VM from cold-boot" / "run glxgears" / "shutdown the VM" cycle.
• With the VM shut down completely (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response (see the "Upload attachment" tab below the reply form).

Here is the VBox.log file :
Just started the box, logged in, start an xterm, run gkxgears and finally shut down (without closing neither th term nor the session).

I used a modified version of glxgears where I only changed the infinite while(1) loop by a for(i=0;i<1000;++i) to get control back over the session.

00:00:01.281072 NumCPUs <integer> = 0x0000000000000002 (2)
00:00:01.456170 CPUM: Logical host processors: 4 present, 4 max, 4 online, online mask: 000000000000000f
00:00:01.456175 CPUM: Physical host cores: 2

You have assigned all your CPUs to the VM. The host is going to run low on resources, since VirtualBox cares about physical processors, not logical ones. See: CPU Cores versus threads. Your i7-3520M has 2 cores.

As for your GPU, the Intel 4000 is just fine. Plenty of capabilities.

Nope.

Setting the CPU to 1 (I already did that before) doesn't change anything and CPU shortage doesn't seem to be the problem : while the Ubuntu box's hanged running glxgear, the system (OS X) reports using only 20% of CPU and anyway, the OS X host is quite responsive (switching desktop works fine : that's how I can eventually kill the Ubuntu VBox by sending a soft reset).

Except the OpenGL warnings, I neither see anything wrong in the log file...

That's all I've got. Other than what we've been through, the logs show that your computer gets a clean bill of health. Try with another distro?

Thanks, Socratis.

Talking with you helped me a lot progress a bit...

In fact, the Ubuntu VM kernel works fine. I tried to run two xterms in Unity, one running the top tool and another to launch glxgear : the kernel behaves
perfectly well, refreshing every second in the second xterm display (as the gears ). In fact, the trouble seems coming from heavily delayed input interrupts (i.e. keyboard & mouse) occurring during heavy OpenGL calls : I loose control of keyboard inputs and/or mouse motions, but in fact, they are not lost, just veeeeeery longly delayed (ie. if I type in something into the second term, it takes seconds before characters display and dragging a window occurs seconds after I did the move, often erratically as I cannot see exactly where the mouse pointer is when I do click).

Now why Unity window manager delays inputs while getting heavy OpenGL calls, I still don't know and try to find a way to investigate further...

I hope it sounds clear enough to you and any new idea welcome...

Thanks again for your time.

More infos :

it's not the Unity WM which looses input interrupts, it's the kernel itself which doesn't get them for the VM (/dev/input/event2 (keyboard) & /dev/input/event6 (virtual box mouse) at least) !

It seems that while the VB subprocess processes OpenGL requests, it looses its ability to update in real time the input event loop...

Sounds really weird

(I remember I red somewhere that the OpenGL Linux driver uses a kind of a dirty hack that makes the display work "on top" of other processes (?), or something like this... could it be related ?)

The question is why is it working fine on mine and not on yours. What are the differences I wonder? Nothing obvious from the logs, except that 2 CPU issue which you have addressed. Beats me...