Description of problem: http://lists.fedoraproject.org/pipermail/devel/2013-April/181502.html Version-Release number of selected component (if applicable): 9.1-6.fc19 How reproducible: After upgrade to 9.1-6.fc19 , glxinfo crash with segfault , glxinfo says: libGL error: failed to load driver: swrast downgrade mesa to f19 base , we don't have this problem
gdb glxinfo r bt from the crash. Also attach /var/log/Xorg.0.log
Created attachment 736564 [details] gdb glxinfo after install all debuginfos
Created attachment 736565 [details] /var/log/Xorg.0.log
Wild guess, is there any rpath involved ?
Also I wonder why the intel glamor module is enforced from the config files. Aren't xorg modules expected to be loaded automatically nowadays ? "Loading /usr/lib64/xorg/modules/libglamoregl.so"
I have same problem, see this bug on rpmfusion bugzilla : https://bugzilla.rpmfusion.org/show_bug.cgi?id=2758 Particularly see comment 5 and 6.
(In reply to comment #6) > I have same problem, see this bug on rpmfusion bugzilla : > https://bugzilla.rpmfusion.org/show_bug.cgi?id=2758 > > Particularly see comment 5 and 6. seems it is related with --enable-glx-tls in .spec
(In reply to comment #7) ... > seems it is related with --enable-glx-tls in .spec Can you reproduce with the affected version of mesa but without xorg-x11-glamor
is anyone seeing this without the binary driver? try reinstalling the binary driver maybe. loading glamor explicitly is due to an interaction between glamor and glx load ordering, but nvidia glx shouldn't have any issues in theory.
(In reply to comment #9) from http://pkgs.fedoraproject.org/cgit/mesa.git/commit/?id=3d536441811fefd2a7b35eebb8e3288a3f5e1b86 -BuildRequires: libtalloc-devel why ? what propose or could influence in segfault ?
(In reply to comment #8) > (In reply to comment #7) > ... > > seems it is related with --enable-glx-tls in .spec > Can you reproduce with the affected version of mesa but without > xorg-x11-glamor rpm -e xorg-x11-drv-ati.x86_64 xorg-x11-glamor.x86_64 --nodeps doesn't change glxinfo segfault ,
diff --git a/mesa.spec b/mesa.spec index cdf5126..53fccb5 100644 --- a/mesa.spec +++ b/mesa.spec @@ -48,7 +48,7 @@ Summary: Mesa graphics libraries Name: mesa Version: 9.1 -Release: 6%{?dist} +Release: 8%{?dist} License: MIT Group: System Environment/Libraries URL: http://www.mesa3d.org @@ -349,7 +349,6 @@ export CXXFLAGS="$RPM_OPT_FLAGS -fno-rtti -fno-exceptions" --enable-shared-glapi \ --enable-gbm \ --disable-opencl \ - --enable-glx-tls \ %if %{with_hardware} %{?with_vmware:--enable-xa} \ %if 0%{?with_llvm} fix this problem
libtalloc-devel isn't used in mesa anymore, --enable-glx-tls is an upstream configuration flag that we were meant to be using and require in order for ATI open source drivers to work properly. It won't be reverted. I've no idea why the binary driver is choking here, reinstall its libGL and see do things still work. I'm closing this as a Fedora bug unless someone can reproduce with no binary driver installed. Maybe continue in the rpmfusion bug or talk to nvidia.
(In reply to comment #13) > libtalloc-devel isn't used in mesa anymore, --enable-glx-tls is an upstream > configuration flag that we were meant to be using and require in order for > ATI open source drivers to work properly. It won't be reverted. > > I've no idea why the binary driver is choking here, reinstall its libGL and > see do things still work. > > I'm closing this as a Fedora bug unless someone can reproduce with no binary > driver installed. > > Maybe continue in the rpmfusion bug or talk to nvidia. You say it's not a bug, but : - for test I install mesa 9.1-6 on my Fedora 18 (with nvidia drivers installed), and I have same problem : direct rendering= NO. - that work fine with mesa 9.1-3. So I think that the 9.1-6 version introduce this bug, and say it is not a bug is not very responsible. That work before and don't work after. If it's not a bug, what is it?
For the record, I'm not reproducing the issue with nvidia binary 304.88 on 32bit with geforce 7. nVidia binary users, please discuss the issue here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2758
(In reply to comment #14) > > If it's not a bug, what is it? Agree, at least you may close with a won't fix.
Created attachment 738338 [details] Patch from openSuSE I'm reopening this ticket as I've got more information about it and a patch which resolves it. The problem is caused by the way the dynamic library loader decides which library it should use when there are multiple candidates. The latest mesa has changed the name which it exposes to the dynamic library loader. This change has caused the mesa libGL to have a higher preference than the nVidia libGL With mesa-9.1-3.fc19: $ ldconfig -p | grep libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1 libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1 libGL.so.1 (libc6) => /lib/libGL.so.1 With mesa-9.1-6.fc19: $ ldconfig -p | grep libGL.so.1 libGL.so.1 (libc6,x86-64, OS-ABI: Linux 2.4.20) => /lib64/libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1 libGL.so.1 (libc6) => /lib/libGL.so.1 With the addition of the 'OS-ABI: Linux 2.4.20' label the mesa libGL always gets loaded instead of the nVidia libGL and causes breakage for environments where the nVidia driver is installed. This issue was already reported in 2010 to upstream mesa and contains a patch to 'fix' the problem: https://bugs.freedesktop.org/show_bug.cgi?id=26663 The openSuSE folks also ran into this issue recently and updated the patch so it can be applied on the latest mesa: https://bugzilla.novell.com/show_bug.cgi?id=765294 I've attached the openSuSE patch to this ticket so you can consider applying it to the mesa package
Note that this only affects x86_64. i686 is not affected.
Same problem here, I actually thought it was a glibc bug as I've never had the chance to try mesa-9.1-3.fc19. https://bugzilla.redhat.com/show_bug.cgi?id=951910 I'm closing the other bug down.
According to the changelog on kernel.org it has been released on 28th november 2002!... We get rid of much more recent stuff in Fedora.... According to freedesktop.org bug #26663 this seems pretty trivial. Thanks, --Simone
hi , Erik nice catch, thanks. I confirm, this patch, on this report, fix glxinfo segfault. I think fix on upstream, is a better solution ...
err I forgot renable-glx , I have to test it again , tomorrow, not today , big sorry :/ Comment #21 could be not corrected ...
For test I rebuild mesa 9.1-6 (with rpmbuild and mock) with OpenSuse patch, and --enable-glx-tls \ in mesa.spec, and for me that solve problem : Direct rendering= YES [dominique@host ~]$ ldconfig -p | grep libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1 libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1 libGL.so.1 (libc6) => /lib/libGL.so.1 [dominique@host ~]$ If that help you.
hi, OK works also here and also loads glamor [ 21.946] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 24.570] (II) Loading /usr/lib64/xorg/modules/nvidia-304xx-304.88/libglx.so [ 24.607] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
(In reply to comment #24) > hi, > OK works also here and also loads glamor > [ 21.946] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so > [ 24.570] (II) Loading > /usr/lib64/xorg/modules/nvidia-304xx-304.88/libglx.so > [ 24.607] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so glamor is also load : [ 4.012] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 4.096] (II) Loading /usr/lib64/nvidia/xorg/libglx.so [ 4.150] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so
Dominique , it is fixed upstream, in this patch http://cgit.freedesktop.org/mesa/mesa/patch/?id=904b03824b4c5cc24649aa69dd1a557ddfd5dda3 which means this patch can be add in Fedora before new upstream release. reference : https://bugs.freedesktop.org/show_bug.cgi?id=26663 Best regards,
(In reply to comment #26) > Dominique , > it is fixed upstream, > > in this patch > http://cgit.freedesktop.org/mesa/mesa/patch/ > ?id=904b03824b4c5cc24649aa69dd1a557ddfd5dda3 > > which means this patch can be add in Fedora before new upstream release. > > reference : > https://bugs.freedesktop.org/show_bug.cgi?id=26663 > > Best regards, OK... For test I rebuild mesa with this patch, and it's good: [dominique@host ~]$ ldconfig -p | grep libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1 libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1 libGL.so.1 (libc6) => /lib/libGL.so.1 [dominique@host ~]$ ldconfig -p | grep libglamor libglamor.so.0 (libc6,x86-64) => /lib64/libglamor.so.0 libglamor.so.0 (libc6) => /lib/libglamor.so.0
mesa-9.1.1-1.fc19 in update testing fix the bug for me : Direct rendering= YES [dominique@host ~]$ ldconfig -p | grep libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1 libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1 libGL.so.1 (libc6) => /lib/libGL.so.1 [dominique@host ~]$ ldconfig -p | grep libglamor libglamor.so.0 (libc6,x86-64) => /lib64/libglamor.so.0 libglamor.so.0 (libc6) => /lib/libglamor.so.0
mesa-9.1.1-1.fc19 has gone into the updates and the bug is fixed. Thanks, --Simone