Extremely slow graphics with opensolaris build122 -> X.org vesa driver bug (packing issue)

[hajma]

with opensolaris build122 as guest, the gui inside the guest is extremely slow, just repainting a gnome-terminal window takes several seconds. The non-graphical stuff seems to perform normally. During the repaint I can see in prstat the X process eating 100%cpu This works just fine with all osol<=121

This was observed with vbox 2.2.0(from distro), 3.0.4 and 3.0.6beta(from virtualbox.org)

Host is a toshiba tecra M9 laptop with 4gb ram and 2x2ghz cpu, nvidia gpu, running 32bit Mandriva 2009.1 guest additions are not installed. vtx is enabled. the vm's are just defaults created by the wizard (solaris->opensolaris)

[hajma]

log

[Sander van Leeuwen]

Are you in VESA or VGA mode? VESA is fine, but VGA will kill performance. Installing the guest additions is recommended in any case.

[hajma]

I am observing the same behaviour with vesa Unfortunately I cannot afford to install the guest additions, they screw up my build environment in the vm. Note a mac user is reporting the same at ​http://www.mail-archive.com/[email protected]/msg43369.html

[hajma]

alo in the meantime I updated vbox to 3.0.6 and the issue persists

[Juergen Keil]

I'm observing the same on a Mac mini host running vbox 3.0.10 on MacOS 10.6.2 (4GB, VT-x enabled), and a 64-bit opensolaris build 127 guest. Drawing the gnome desktop screen takes minutes. Trying to use the gui installer is a paint 'cause it's so slow.

Once the guest system is installed and you install the vbox guest additions, the gui performance is ok.

[Juergen Keil]

vbox log file while opensolaris b127 livecd is booted

[Juergen Keil]

Replying to sandervl73:

Are you in VESA or VGA mode? VESA is fine, but VGA will kill performance.

On the opensolaris live cd the VESA driver is used.

To reproduce the issue, try to boot the current opensolaris live cd on a vbox 3.0.10 64-bit guest vm that has 768 MB of memory defined (i.e. less than 1 GB). Note that in this configuration opensolaris' grub will start the 32-bit kernel, not the the 64-bit kernel!

For some reason the 32-bit VESA driver is detecting too much video memory (my guest has 12 MB video memory defined):

    (II) VESA(0): Total Memory: 2114 64KB banks (135296kB)

(II) VESA(0): initializing int10
(II) VESA(0): Primary V_BIOS segment is: 0xc000
(II) VESA(0): VESA BIOS detected
(II) VESA(0): VESA VBE Version 2.0
(II) VESA(0): VESA VBE Total Mem: 12288 kB               <<<<<<<<<<<<<<<<<< OK
(II) VESA(0): VESA VBE OEM: VirtualBox VBE BIOS http://www.virtualbox.org/
(II) VESA(0): VESA VBE OEM Software Rev: 0.2
(II) VESA(0): VESA VBE OEM Vendor: Sun Microsystems, Inc.
(II) VESA(0): VESA VBE OEM Product: VirtualBox VBE Adapter
(II) VESA(0): VESA VBE OEM Product Rev: Sun VirtualBox Version 3.0.10
(II) VESA(0): virtual address = 0,
	physical address = 0xe0000000, size = 138543104  <<<<<<<<<<<<<<<<< ????
(II) VESA(0): virtual address = d17a0000,
	physical address = 0xa0000, size = 65536         <<<<<<<<<<<<<<<<< ????
(II) VESA(0): Setting up VESA Mode 0x145 (1280x1024)
(==) VESA(0): Default visual is TrueColor

Is the 32-bit VESA driver using slow 64 KB window bank swapping ?

[Juergen Keil]

Xorg.0.log from the build 127 opensolaris live cd, when the 32-bit Xorg server is running

[Sander van Leeuwen]

I have never seen this with e.g. OpenSolaris 200906.

[Juergen Keil]

Replying to sandervl73:

I have never seen this with e.g. OpenSolaris 200906.

That's possible. I think Xorg was updated in later development builds to a never version; and at the same time the build process was changed so that more of Xorg is compiled with SunPro C instead of Gnu C. These changes seem to have broken vesa video memory detection.

More details can be found in ​http://defect.opensolaris.org/bz/show_bug.cgi?id=11374#c8.

I think this isn't a virtualbox bug, but an opensolaris vesa driver driver bug, so I think this ticket can be closed. Maybe with a reference to the above opensolaris bug, or CR 6884183 (but that one isn't visible on bugs.opensolaris.org so I've no idea if someone is working on 6884183).

[Sander van Leeuwen]

Ok, thanks for the analysis. Note that this appears not to be such a big issue on real hardware, because there the overhead is less. Banked mode in a virtual environment (especially with VT-x/AMD-V) is extremely expensive as each VRAM write causes a full world switch.