Bug 972095 - X server fails on 32-bit Fedora 19 with VirtualBox Guest Additions installed
X server fails on 32-bit Fedora 19 with VirtualBox Guest Additions installed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
19
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 15:13 EDT by Ben Liblit
Modified: 2013-07-11 23:03 EDT (History)
12 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.14.2-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-11 23:03:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
suggested fix from upstream (521 bytes, patch)
2013-06-07 15:16 EDT, Ben Liblit
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 59825 None None None Never

  None (edit)
Description Ben Liblit 2013-06-07 15:13:06 EDT
[This is a long description, but here's a summary: X fails under Fedora 19 with VirtualBox.  There is already an upstream bug report and proposed fix at <https://bugs.freedesktop.org/show_bug.cgi?id=59825>.  I've tested the fix; it *does* fix the problem I'm seeing.  Please add that fix to Fedora's build of the X server RPMs.]

I am using VirtualBox (v4.2.12) guests running Fedora 19 beta (RC 3.1) with the xorg-x11-server-Xorg-1.14.1-2.fc19 RPM installed.  My 32-bit Fedora virtual machine works fine before installing Guest Additions.  After Guest Additions are installed, the X server no longer starts correctly.  Instead I am simply left with a completely black screen.  No mouse pointer or text cursor visible at all.

Strangely, my 64-bit Fedora 19 beta (RC 3.1) guest works fine both before and after installing Guest Additions.  So whatever is going wrong here seems to be specific to 32-bit environments.

Once the guest is in this state, it is not completely frozen. I can ssh into it remotely, it responds properly to ACPI shutdown requests, etc.  Just the display is broken.

By ssh'ing in remotely after the failure I can observe that no "X" or "Xorg" process is still running.  So whatever went wrong, it killed the X server entirely.  The last line of "/var/log/Xorg.0.log" reads "(EE) AIGLX error: vboxvideo does not export required DRI extension".  But this is probably *not* the fatal problem.  I see that same message in the X server log for my working 64-bit guest, followed by several more lines that reveal that the X server is falling back on software rendering:

----------------------------------------------------------------
(EE) AIGLX error: vboxvideo does not export required DRI extension
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen
----------------------------------------------------------------

My 32-bit guest's X server apparently dies after printing just the first of the above output.

I've tried ssh'ing in remotely, then launching Xorg within gdb, all as root, to see where the X server is dying. gdb shows the following clues:

----------------------------------------------------------------
... (initial X server output removed for brevity) ...
Initializing built-in extension XFree86-DRI
Initializing built-in extension DRIMissing separate debuginfo for /usr/lib/xorg/modules/drivers/vboxvideo_drv.so
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
Missing separate debuginfo for /usr/lib/dri/vboxvideo_dri.so
Missing separate debuginfo for /lib/VBoxOGLcrutil.so

Program received signal SIGSEGV, Segmentation fault.
_dl_fixup (l=60, reloc_arg=576) at dl-runtime.c:74
74	    = (const void *) (D_PTR (l, l_info[DT_JMPREL]) + reloc_offset);
----------------------------------------------------------------

The gdb-reported stack trace at this point of failure is:

----------------------------------------------------------------
#0  _dl_fixup (l=0x9b62e60, reloc_arg=576) at dl-runtime.c:74
#1  0xb7748e70 in _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:36
#2  0xb6d308b2 in __glXDRIscreenProbe (pScreen=0x9b66948) at glxdri.c:1148
#3  0xb6d274d3 in GlxExtensionInit () at glxext.c:355
#4  0x08107625 in InitExtensions (argc=argc@entry=1, argv=argv@entry=0xbfe03ef4) at ../../../mi/miinitext.c:337
#5  0x080681e0 in main (argc=1, argv=0xbfe03ef4, envp=0xbfe03efc) at main.c:208
----------------------------------------------------------------

I originally reported this as a VirtualBox bug: <https://www.virtualbox.org/ticket/11821>.  A comment there directed me to a similar Arch Linux bug report: <https://bugs.archlinux.org/task/33229>.  Reading that, I agree that these are the same issue.  The Arch Linux bug report eventually led to an upstream bug report: <https://bugs.freedesktop.org/show_bug.cgi?id=59825>.  That report includes a suggested fix.  The suggested fix is not already present in the Fedora 19 RPMs.  I added that fix to a custom rebuild of the xorg-x11-server-Xorg-1.14.1-4.fc19 RPM.  I find that it works: the problem I describe above goes away with this fix added.  Can we get that fix added to the official Fedora X server RPMs as well?
Comment 1 Ben Liblit 2013-06-07 15:16:57 EDT
Created attachment 758301 [details]
suggested fix from upstream

This is the suggested fix from upstream <https://bugs.freedesktop.org/show_bug.cgi?id=59825#c1>.  I've tested it and I find that it works; the problem I describe vanishes with this fix applied.
Comment 2 Fernando Cassia 2013-06-24 20:23:43 EDT
I can confirm that this affects F19 beta, on the latest Virtualbox. I installed the guest additions and lost access to the VM, video is all scrambled. However the VM continues working, but is unusable. If I send it a shutdown signal, the VM shuts down.

Screenshots:

http://img812.imageshack.us/img812/6610/rsmt.png
http://img545.imageshack.us/img545/3827/0wp2.png

FC
Comment 3 Adam Williamson 2013-07-01 01:47:55 EDT
ajax, airlied, can you look at the suggestion from upstream and see if it looks valid? Thanks.
Comment 4 Michael Best 2013-07-06 00:28:06 EDT
Also saw this on Fedora 19 64 bit, with guest additions installed.  I turned off 3d video acceleration in machine configuration and it stopped crashing.
Comment 5 Sergio Monteiro Basto 2013-07-08 10:16:19 EDT
Well , Xorg team 
this is part of xorg-x11-server , can this be fixed upstream ? and or patch to 
xorg-x11-server ?
 
--- a/glx/glxdri.c	2013-01-24 22:14:35.216092949 +0100
+++ b/glx/glxdri.c	2013-01-24 22:13:48.499427991 +0100
@@ -971,6 +971,8 @@ __glXDRIscreenProbe(ScreenPtr pScreen)
     size_t buffer_size;
     ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
 
+    framebuffer.base = NULL;
+
Comment 6 Sergio Monteiro Basto 2013-07-08 10:21:00 EDT
(In reply to Michael Best from comment #4)
> Also saw this on Fedora 19 64 bit, with guest additions installed.  I turned
> off 3d video acceleration in machine configuration and it stopped crashing.

So, and just remove and not load vboxvideo.ko on guest additions ? doesn't also fix the problem on 32 bits guests  ? 

rm /usr/lib/modules/`uname -r`/extra/VirtualBox/vboxvideo.ko
rmmod vboxvideo 
and start X  ?
Comment 7 Fedora Update System 2013-07-09 06:29:29 EDT
xorg-x11-server-1.14.2-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.2-3.fc19
Comment 8 Fedora Update System 2013-07-09 21:29:17 EDT
Package xorg-x11-server-1.14.2-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.14.2-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-12681/xorg-x11-server-1.14.2-3.fc19
then log in and leave karma (feedback).
Comment 9 Volker Braun 2013-07-10 00:21:01 EDT
Correction: Update with
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-Xorg-1.14.2-3.fc19'
Comment 10 Sergio Monteiro Basto 2013-07-10 13:32:24 EDT
I like update with 
yum --advisory=FEDORA-2013-12681 --enablerepo=updates-testing update  (as root) 

and it works ! 

Now we need upstream this mini patch ASAP 

Thanks,
Comment 11 Peter Hutterer 2013-07-10 19:45:57 EDT
Sergio: patch is already upstream as cc3d1a5a6120e721a46c67446ba68f5596055633, I'll get it into the 1.14 branch.
Comment 12 Fedora Update System 2013-07-11 23:03:55 EDT
xorg-x11-server-1.14.2-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.