Bug 1285666

Summary: GLX: could not load software renderer
Product: [Fedora] Fedora Reporter: poma <pomidorabelisima>
Component: mesaAssignee: Igor Gnatenko <ignatenko>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ajax, awilliam, fschwarz, ignatenko, rdieter, robatino
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-03 21:13:06 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:
Bug Depends On:    
Bug Blocks: 1230431    
Attachments:
Description Flags
Fix GLX: could not load software renderer none

Description poma 2015-11-26 08:28:11 UTC
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

Comment 1 poma 2015-11-27 08:39:47 UTC
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

Comment 2 poma 2015-11-27 08:44:07 UTC
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?

Comment 3 Igor Gnatenko 2015-11-27 08:50:14 UTC
(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.

Comment 4 poma 2015-11-27 10:09:00 UTC
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.

Comment 5 Adam Williamson 2015-12-01 19:18:45 UTC
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 .

Comment 6 Adam Williamson 2015-12-01 23:04:31 UTC
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.

Comment 7 Adam Williamson 2015-12-02 15:17:05 UTC
*** Bug 1287142 has been marked as a duplicate of this bug. ***

Comment 8 Adam Williamson 2015-12-02 15:18:21 UTC
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.

Comment 9 Igor Gnatenko 2015-12-02 15:50:02 UTC
To be precised it was not scratch build, it is usual build. It will appear in next rawhide compose.

Comment 10 Igor Gnatenko 2015-12-03 12:03:04 UTC
Appeared in today's compose.

Comment 11 poma 2015-12-03 19:16:56 UTC
(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.

Comment 12 Adam Williamson 2015-12-03 19:41:24 UTC
No, that is not the fix that was included in Rawhide build. As I said in #c8, I tested that fix and it works.

Comment 13 poma 2015-12-03 21:12:08 UTC
(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.