Latest Ubuntu & 3D acceleration

[FrancoisD]

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 ?

[socratis]

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).

[FrancoisD]

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.

[socratis]

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.

[FrancoisD]

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...

[socratis]

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?

[FrancoisD]

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.

[FrancoisD]

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 ?)

[socratis]

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...