In VirtualBox 5 I cannot enable second monitor

I set in preferences that I want to have 2 displays. However, in Linux I see only one. When I right click on the screen icon in the status bar, I see "Second virtual display" and all the options are greyed out except for "Enable". Unfortunately, nothing happens when I click on "Enable".

Linux says:

$> xrandr 
Screen 0: minimum 64 x 64, current 1920 x 976, maximum 32766 x 32766
VGA-0 connected primary 1920x976+0+0 0mm x 0mm
 1920x976 60.00*+
 2560x1600 60.00 
 2560x1440 60.00 
 2048x1536 60.00 
 1920x1600 60.00 
 1920x1080 60.00 
 1600x1200 60.00 
 1680x1050 60.00 
 1400x1050 60.00 
 1280x1024 60.00 
 1024x768 60.00 
 800x600 60.00 
 640x480 60.00

$> systemctl status vboxadd.service 
vboxadd.service - LSB: VirtualBox Linux Additions kernel modules
 Loaded: loaded (/etc/init.d/vboxadd)
 Active: active (exited) since k 2015年08月25日 16:12:09 CEST; 12min ago
 Process: 7224 ExecStop=/etc/init.d/vboxadd stop (code=exited, status=1/FAILURE)
 Process: 7242 ExecStart=/etc/init.d/vboxadd start (code=exited, status=0/SUCCESS)
aug 25 16:12:09 linux-suse.site vboxadd[7224]: Stopping VirtualBox Additions ..failed
aug 25 16:12:09 linux-suse.site vboxadd[7224]: (Cannot unload module vboxguest)
aug 25 16:12:09 linux-suse.site vboxadd[7242]: Starting the VirtualBox Guest Additions ..done

Host: Win7 x64
Guest: openSUSE 13.2 with kernel 3.16

Virtualbox.log

I'm sorry, but I really can't reproduce this. Can you give a reproduction scenario with a new VM?

Did some substantial diagnosis of this problem. It appears that the VBoxVideo driver version 5.0.4_OSEr102546 has this issue; the following was observed:

Workaround therefore is to not use the distribution provided guest additions, but remove them and install from the ISO image provided by VirtualBox itself.

Would you mind investigating a little bit more? For a start, in the log file you provided I saw lines like "Restoring guest size-hint for screen 1 to 0x0" which looked rather strange to me, and where I do not immediately see the connection to the Additions version. Could you check the log files for the machines you tested to see if there is a correlation with the second screen issue?

The output of xrandr in the guest when you the screen is not available would be interesting too.

And /var/log/Xorg.0.log from the guests.

Version 5.0.4 is affected, too. I found out that many other users are experiencing this bug.

Some more information can be found on public forums:

• ​https://forums.virtualbox.org/viewtopic.php?f=6&t=69095
• ​https://bbs.archlinux.org/viewtopic.php?id=200217
• ​https://bugs.archlinux.org/task/45748?project=5

xrandr output:

xrandr program version 1.4.3
Server reports RandR version 1.4
Screen 0: minimum 64 x 64, current 1920 x 976, maximum 32766 x 32766
VGA-0 connected primary 1920x976+0+0 (0x1e2) normal (normal) 0mm x 0mm
 Identifier: 0x3f
 Timestamp: 17535
 Subpixel: unknown
 Gamma: 1.0:1.0:1.0
 Brightness: 1.0
 Clones: 
 CRTC: 0
 CRTCs: 0
 Transform: 1.000000 0.000000 0.000000
 0.000000 1.000000 0.000000
 0.000000 0.000000 1.000000
 filter: 
 1920x976 (0x1e2) 113.479MHz *current +preferred
 h: width 1920 start 1922 end 1924 total 1926 skew 0 clock 58.92KHz
 v: height 976 start 978 end 980 total 982 clock 60.00Hz
 2560x1600 (0x41) 247.259MHz
 h: width 2560 start 2562 end 2564 total 2566 skew 0 clock 96.36KHz
 v: height 1600 start 1602 end 1604 total 1606 clock 60.00Hz
 2560x1440 (0x42) 222.626MHz
 h: width 2560 start 2562 end 2564 total 2566 skew 0 clock 86.76KHz
 v: height 1440 start 1442 end 1444 total 1446 clock 60.00Hz
 2048x1536 (0x43) 190.036MHz
 h: width 2048 start 2050 end 2052 total 2054 skew 0 clock 92.52KHz
 v: height 1536 start 1538 end 1540 total 1542 clock 60.00Hz
 1920x1600 (0x44) 185.589MHz
 h: width 1920 start 1922 end 1924 total 1926 skew 0 clock 96.36KHz
 v: height 1600 start 1602 end 1604 total 1606 clock 60.00Hz
 1920x1080 (0x45) 125.498MHz
 h: width 1920 start 1922 end 1924 total 1926 skew 0 clock 65.16KHz
 v: height 1080 start 1082 end 1084 total 1086 clock 60.00Hz
 1600x1200 (0x46) 116.210MHz
 h: width 1600 start 1602 end 1604 total 1606 skew 0 clock 72.36KHz
 v: height 1200 start 1202 end 1204 total 1206 clock 60.00Hz
 1680x1050 (0x47) 106.824MHz
 h: width 1680 start 1682 end 1684 total 1686 skew 0 clock 63.36KHz
 v: height 1050 start 1052 end 1054 total 1056 clock 60.00Hz
 1400x1050 (0x48) 89.084MHz
 h: width 1400 start 1402 end 1404 total 1406 skew 0 clock 63.36KHz
 v: height 1050 start 1052 end 1054 total 1056 clock 60.00Hz
 1280x1024 (0x49) 79.474MHz
 h: width 1280 start 1282 end 1284 total 1286 skew 0 clock 61.80KHz
 v: height 1024 start 1026 end 1028 total 1030 clock 60.00Hz
 1024x768 (0x4a) 47.833MHz
 h: width 1024 start 1026 end 1028 total 1030 skew 0 clock 46.44KHz
 v: height 768 start 770 end 772 total 774 clock 60.00Hz
 800x600 (0x40) 29.306MHz
 h: width 800 start 802 end 804 total 806 skew 0 clock 36.36KHz
 v: height 600 start 602 end 604 total 606 clock 60.00Hz
 640x480 (0x4b) 18.837MHz
 h: width 640 start 642 end 644 total 646 skew 0 clock 29.16KHz
 v: height 480 start 482 end 484 total 486 clock 60.00Hz

The following does not help:

• turning on/off the 3D acceleration
• changing monitor numbers from 2 -> 1, then 1 -> 2 (or play this with 3)
  • either from GUI
  • or from VBoxManage
• removing any of the following lines from <machinename>.vbox file:

  <GuestProperty name="/VirtualBox/GuestAdd/Vbgl/Video/0" value="1920x976x32,0x0,1" timestamp="1445263857226959000" flags=""/>
  <GuestProperty name="/VirtualBox/GuestAdd/Vbgl/Video/1" value="800x600x32,0x0,1" timestamp="1445256421803528100" flags=""/>
  <GuestProperty name="/VirtualBox/GuestAdd/Vbgl/Video/2" value="800x600x32,0x0,1" timestamp="1445256426396946600" flags=""/>
  <GuestProperty name="/VirtualBox/GuestAdd/Vbgl/Video/SavedMode" value="1920x976x32" timestamp="1445263857227459100" flags=""/>
  

Virtualbox 5.0.10 is affected, too.

I can reproduce this bug, and I think I found the root cause. I did create a quick and dirty patch. Everything is explained here : ​https://bugs.archlinux.org/task/45748

Basically I did add memory barrier inside the VBoxHGSMIBufferSubmit() near VBoxVideoCmnPortWriteUlong()

To properly fix it, I think the pointer returned by VBoxHGSMIBufferAlloc() shall be volatile

benjarobin, thanks a lot for spotting this! The fix will be included in the next VirtualBox release.

The actual changeset is r59179. As you already found out, the I/O instruction for submitting HGSMI commands has side effects, therefore the memory clobber will prevent gcc from doing dead-code elemination.

Fix is part of VBox 5.0.12.