Bug 972095

Summary: X server fails on 32-bit Fedora 19 with VirtualBox Guest Additions installed
Product: [Fedora] Fedora Reporter: Ben Liblit <liblit>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: airlied, ajax, awilliam, goodyca48, mbest, mihai, mtasaka, peter.hutterer, robatino, sergio, vbraun.name, xgl-maint
Target Milestone: ---Keywords: CommonBugs, Patch
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard: https://fedoraproject.org/wiki/Common_F19_bugs#vbox-32-guest
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-12 03:03:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
suggested fix from upstream none

Description Ben Liblit 2013-06-07 19:13:06 UTC
[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 19:16:57 UTC
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-25 00:23:43 UTC
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 05:47:55 UTC
ajax, airlied, can you look at the suggestion from upstream and see if it looks valid? Thanks.

Comment 4 Michael Best 2013-07-06 04:28:06 UTC
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 Basto 2013-07-08 14:16:19 UTC
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 Basto 2013-07-08 14:21:00 UTC
(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 10:29:29 UTC
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-10 01:29:17 UTC
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 04:21:01 UTC
Correction: Update with
# su -c 'yum update --enablerepo=updates-testing xorg-x11-server-Xorg-1.14.2-3.fc19'

Comment 10 Sergio Basto 2013-07-10 17:32:24 UTC
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 23:45:57 UTC
Sergio: patch is already upstream as cc3d1a5a6120e721a46c67446ba68f5596055633, I'll get it into the 1.14 branch.

Comment 12 Fedora Update System 2013-07-12 03:03:55 UTC
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.