VirtualBox

Ticket #4926 (closed defect: invalid)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: hajma Owned by:
Priority: major Component: other
Version: VirtualBox 3.0.4 Keywords:
Cc: Guest type: Solaris
Host type: Linux

Description

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)

Attachments

b122test2-2009-09-08-08-58-37.log Download (43.5 KB) - added by hajma 5 years ago.
log
OpenSolaris 2010.03 b127-2009-11-14-18-49-00.log Download (36.7 KB) - added by jkeil2 4 years ago.
vbox log file while opensolaris b127 livecd is booted
Xorg.OSol_LiveCD.log Download (34.4 KB) - added by jkeil2 4 years ago.
Xorg.0.log from the build 127 opensolaris live cd, when the 32-bit Xorg server is running

Change History

Changed 5 years ago by hajma

log

comment:1 follow-up: ↓ 5 Changed 5 years ago by sandervl73

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

comment:2 Changed 5 years ago by 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/opensolaris-discuss@opensolaris.org/msg43369.html

comment:3 Changed 5 years ago by hajma

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

comment:4 Changed 4 years ago by jkeil2

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.

Changed 4 years ago by jkeil2

vbox log file while opensolaris b127 livecd is booted

comment:5 in reply to: ↑ 1 Changed 4 years ago by jkeil2

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 ?

Changed 4 years ago by jkeil2

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

comment:6 follow-up: ↓ 7 Changed 4 years ago by sandervl73

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

comment:7 in reply to: ↑ 6 Changed 4 years ago by jkeil2

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

comment:8 Changed 4 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to invalid
  • Summary changed from extremely slow graphics with opensolaris build122 to Extremely slow graphics with opensolaris build122 -> X.org vesa driver bug (packing issue)

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use