Description of problem: GLX: could not load software renderer Version-Release number of selected component (if applicable): mesa-libGL-11.2.0-0.devel.1.86fc97d.fc24.x86_64 How reproducible: 101% Steps to Reproduce: 1. Run "xfwm4 --compositor=on" (revision e180e80.20151109) on QXL Actual results: Segmentation fault Expected results: -NONE- Segmentation fault Additional info: - GLX compositor: Program terminated with signal SIGSEGV, Segmentation fault. https://bugzilla.xfce.org/show_bug.cgi?id=12331 - GLX: could not load software renderer https://bugs.freedesktop.org/show_bug.cgi?id=93112
Created attachment 1099619 [details] Fix GLX: could not load software renderer $ grep -i glx /var/log/Xorg.0.log [ 43.027] (II) LoadModule: "glx" [ 43.029] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 43.220] (II) Module glx: vendor="X.Org Foundation" [ 43.220] (==) AIGLX enabled [ 43.289] (II) AIGLX: Screen 0 is not DRI2 capable [ 43.289] (EE) AIGLX: reverting to software rendering [ 44.566] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 44.567] (II) AIGLX: Loaded and initialized swrast [ 44.567] (II) GLX: Initialized DRISWRAST GL provider for screen 0 $ glxinfo | grep -w renderer OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits) $ rpm -q mesa-dri-drivers mesa-dri-drivers-11.2.0-0.devel.2.59cfb21.fc24.x86_64
BTW http://pkgs.fedoraproject.org/cgit/mesa.git/tree/Makefile#n22 sanitize: clone vl_mpeg12_decoder.c vl_decoder.c What's the rationale for that?
(In reply to poma from comment #2) > BTW > http://pkgs.fedoraproject.org/cgit/mesa.git/tree/Makefile#n22 > sanitize: clone vl_mpeg12_decoder.c vl_decoder.c > > What's the rationale for that? Those are non-free.
What exactly is particular to these two files, and not with others with the same license? http://www.mesa3d.org/license.html says nothing in particular of the two. "Sanitation" began - 2015-05-17 http://pkgs.fedoraproject.org/cgit/mesa.git/commit/Makefile?id=7f1320a Why then? Please explain, if not problem.
They aren't relevant to this bug; this bug almost certainly dates to the new mesa snapshot on 2015-11-22 , http://koji.fedoraproject.org/koji/buildinfo?buildID=700809 . These errors are not present in openQA test logs from 2015-11-22, they start appearing in openQA test logs starting 2015-11-23, which is exactly when that mesa build would have landed. Proposing as an Alpha blocker: this makes both GNOME and KDE live images non-bootable on any system which relies on software rendering, including most VMs. That's a conditional violation of "All release-blocking images must boot in their supported configurations.", https://fedoraproject.org/wiki/Fedora_24_Alpha_Release_Criteria#Release-blocking_images_must_boot . If not Alpha, this is certainly a Beta blocker, violates both Beta virt criteria, https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Self_hosting_virtualization .
I tested a build with 0001-virgl-pipe_virgl_create_screen-is-not-static.patch included, but it doesn't appear to resolve this bug. GNOME still boots to the Oh No! screen, the same error messages are still present in the logs.
*** Bug 1287142 has been marked as a duplicate of this bug. ***
Igor sent me a scratch build which seems to work: http://koji.fedoraproject.org/koji/taskinfo?taskID=12029369 he says he'll send the fix through as an official build soon.
To be precised it was not scratch build, it is usual build. It will appear in next rawhide compose.
Appeared in today's compose.
(In reply to awilliam from comment #6) > I tested a build with > 0001-virgl-pipe_virgl_create_screen-is-not-static.patch included, but it > doesn't appear to resolve this bug. GNOME still boots to the Oh No! screen, > the same error messages are still present in the logs. Happy camper, here we go again.
No, that is not the fix that was included in Rawhide build. As I said in #c8, I tested that fix and it works.
(In reply to awilliam from comment #12) > No, that is not the fix that was included in Rawhide build. As I said in > #c8, I tested that fix and it works. Of course not, there are more than 100 commitas in between broken and the working one. And you gone with the single one. In the end Igor went over 200. As it was difficult to apply tested patch I sent. For both of you, happy camper is euphemism.