Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1285666 - GLX: could not load software renderer
Summary: GLX: could not load software renderer
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Igor Gnatenko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1287142 (view as bug list)
Depends On:
Blocks: F24AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2015-11-26 08:28 UTC by poma
Modified: 2015-12-03 21:13 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-03 21:13:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Fix GLX: could not load software renderer (5.97 KB, patch)
2015-11-27 08:39 UTC, poma
no flags Details | Diff

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.


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