View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000714 | channel: elrepo/el7 | kmod-nvidia | public | 2017-01-27 16:54 | 2017-09-10 07:59 |
Reporter | jchan | Assigned To | pperry | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Summary | 0000714: glxgears | ||||
Description | running glxgears using the 375.26 driver in an xterm or in RealVNC causes glxgears to crash with this message. Error: couldn't get an RGB, Double-buffered visual However, I don't have this issue on the 367.57 driver, or if I install the 375 driver directly from NVIDIA. | ||||
Tags | No tags attached. | ||||
Attached Files | libGLX_indirect.diff (2,983 bytes)
diff --git a/nvidia-x11-drv/el6/nvidia-x11-drv.spec b/nvidia-x11-drv/el6/nvidia-x11-drv.spec index c81dabc..2158905 100644 --- a/nvidia-x11-drv/el6/nvidia-x11-drv.spec +++ b/nvidia-x11-drv/el6/nvidia-x11-drv.spec @@ -261,9 +261,6 @@ pushd nvidiapkg %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGL.so.1 %{__ln_s} libGLX.so.0 $RPM_BUILD_ROOT%{nvidialibdir}/libGLX.so %{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGLX_nvidia.so.0 -%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libGLX_indirect.so.0 -# Fixes bug http://elrepo.org/bugs/view.php?id=714 -%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{_libdir}/libGLX_indirect.so.0 # Added libnvcuvid.so in 260.xx series driver %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libnvcuvid.so %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialibdir}/libnvcuvid.so.1 @@ -309,9 +306,6 @@ pushd nvidiapkg %{__ln_s} libGL.so.1.0.0 $RPM_BUILD_ROOT%{nvidialib32dir}/libGL.so.1 %{__ln_s} libGLX.so.0 $RPM_BUILD_ROOT%{nvidialib32dir}/libGLX.so %{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libGLX_nvidia.so.0 -%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libGLX_indirect.so.0 -# Fixes bug http://elrepo.org/bugs/view.php?id=714 -%{__ln_s} libGLX_nvidia.so.%{version} $RPM_BUILD_ROOT%{_prefix}/lib/libGLX_indirect.so.0 %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libnvcuvid.so %{__ln_s} libnvcuvid.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libnvcuvid.so.1 %{__ln_s} libnvidia-encode.so.%{version} $RPM_BUILD_ROOT%{nvidialib32dir}/libnvidia-encode.so @@ -389,6 +383,11 @@ echo %{nvidialib32dir} >> $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/nvidia.conf echo %{_prefix}/lib/vdpau >> $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/nvidia.conf %endif +# Install scriptlets to set GLX vendor name +%{__mkdir_p} $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/ +echo "export __GLX_VENDOR_LIBRARY_NAME=nvidia" > $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/nvidia.sh +echo "setenv __GLX_VENDOR_LIBRARY_NAME nvidia" > $RPM_BUILD_ROOT%{_sysconfdir}/profile.d/nvidia.csh + popd %clean @@ -476,6 +475,7 @@ fi ||: %config(noreplace) %{_sysconfdir}/modprobe.d/nvidia.conf %config %{_sysconfdir}/ld.so.conf.d/nvidia.conf %config %{_sysconfdir}/udev/makedev.d/60-nvidia.nodes +%config %{_sysconfdir}/profile.d/nvidia.*sh %{_sysconfdir}/OpenCL/vendors/nvidia.icd %{_sysconfdir}/vulkan/icd.d/nvidia_icd.json @@ -485,7 +485,6 @@ fi ||: %{nvidialibdir}/alternate-install* %dir %{nvidialibdir}/tls %{nvidialibdir}/tls/lib* -%{_libdir}/libGLX_indirect.so.0 %{_libdir}/vdpau/libvdpau_nvidia.* %{_libdir}/xorg/modules/drivers/nvidia_drv.so %dir %{_libdir}/xorg/modules/extensions/nvidia @@ -499,7 +498,6 @@ fi ||: %{nvidialib32dir}/lib* %dir %{nvidialib32dir}/tls %{nvidialib32dir}/tls/lib* -%{_prefix}/lib/libGLX_indirect.so.0 %{_prefix}/lib/vdpau/libvdpau_nvidia.* %endif | ||||
Reported upstream | |||||
|
The only major change I'm aware of between 367.xx and 375.xx is that we now enable GLVND by default, but nvidia were already doing this so unless you were running non-GLVND libs on your test install directly from nvidia, it doesn't explain the difference in behaviour between our package(s) and installing direct from nvidia. If you can figure out what's changed / broken, I'll be happy to fix if it's an issue in our packaging of the driver. |
|
Duplicate of http://elrepo.org/bugs/view.php?id=713 |
|
In order to help better understand the issue and potentially fix it, I'm trying to replicate the issue. Are you just opening an xterm window locally on an el7 install and running glxgears? If so, I am unable to replicate this behaviour. I don't have VNC or any remote connections to my test box to be able to replicate. |
|
Thants for the repsonse! Its when I run a xTerm on my local machine (XQuartz on OSX or Mobaxterm on Windows) and ssh into a remote el7 host and run glxgears. I have yet to try this on a Linux laptop, but I'm pretty sure I'll get the same result. |
|
Hi at all, same problem here, on an el6 installation. I've solved with a simlink to /usr/lib64/nvidia/libGLX_indirect.so.0 in /usr/lib64 ln -s /usr/lib64/nvidia/libGLX_indirect.so.0 /usr/lib64/libGLX_indirect.so.0 there are a lot of people around with the same problem (search on google for 'nvidia libGLX_indirect.so.0'). Probably the problem is related to the new GLVND support of NVIDIA driver (but I'm not sure). Some references here: https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/ https://bugs.freedesktop.org/show_bug.cgi?id=99987#c7 https://bugzilla.redhat.com/show_bug.cgi?id=1413579#57 |
|
Thanks for the suggested fix. If others could confirm it fixes the issue? I can queue the fix for the next release and users can apply the fix manually for now. |
|
Hi! Thank you for the follow up! it looks like adding in the softlinks to libGLX fixed the issue for me! -Jed |
|
Thanks for confirming Jed. The fix will be in the next package release, as you have a workaround for now. |
|
Packages for version 384.59 have just been released and contain osmiza's fix so should fix this issue. If someone could confirm these updated packages now fix the issue, that would be great. Thanks |
|
This symlink thing is a bad hack. After ldconfig is run, you get this in /usr/lib[64]: libGLX_indirect.so.0 -> nvidia/libGLX_indirect.so.0 libGLX_nvidia.so.0 -> libGLX_indirect.so.0 The first link is the "fix" from the updated package, the second link is created by ldconfig because the SONAME of libGLX_indirect.so.0 is in fact libGLX_nvidia.so.0. Now we get a second entry /usr/lib64/libGLX_nvidia.so.0 in /etc/ld.so.cache in addition to /usr/lib64/nvidia/libGLX_nvidia.so.0. On the other hand, /usr/lib64/libGLX_indirect.so.0 still gets no entry in /etc/ld.so.cache because that's not the SONAME of any library. If only works because in the end, ld.so will manually go through /usr/lib[64], something it doesn't do for usr/lib[64]/nvidia. A clean solution would be to remove _all_ libGLX_indirect.so.0 links and export __GLX_VENDOR_LIBRARY_NAME=nvidia instead. |
|
@rg, Thanks for the analysis. Would you be able to submit a patch, either here or as a pull request on github: https://github.com/elrepo/packages As an aside, I have been considering a switch in approach, and instead of installing all the nvidia libs to /usr/lib[64]/nvidia/, just install everything to /usr/lib[64], apart from libGL.so.1 which conflicts with libGL.so.1 from the mesa-libGL distro package and would still need to be installed elsewhere. This would presumably resolve this issue, plus I don't think this is the first time we've run into problems with some libs in /usr/lib[64]/nvidia/ not being found. Any thoughts? |
|
Similar issue reported on Fedora here: https://bugzilla.redhat.com/show_bug.cgi?id=1427174 From that bug, Hans de Goede writes in comment 31: "Libglvnd relies on a GLX extension to tell it which vendor library to use, and if the server doesn't support that extension (which I'm assuming it doesn't), then it'll try to load a vendor library named libGLX_indirect.so.0 instead. The reason for that is so that indirect rendering can still work when you connect to a remote X server. libGLX_indirect.so.0 should just be a symlink to another vendor. For indirect rendering, any vendor will do, since they should all speak the same GLX protocol. But, if libGLX_indirect.so.0 doesn't exist, then libglvnd won't be able to find any vendor library to load, so it won't be able to handle any GLX calls at all." Later in the same post he suggests linking libGLX_indirect.so.0 to the mesa lib on the basis any vendor lib will do for indirect GLX: sudo ln -s /usr/lib64/libGLX_mesa.so.0 /usr/lib64/libGLX_indirect.so.0 and then proposes to add that symlink to the mesa package in Fedora, a change that has been made in Fedora 25 To avoid conflict, rpmfusion now symlink against mesa in fedora 25 and above, and nvidia in earlier releases: # GlVND %if 0%{?fedora} >= 25 # We keep the same symlink than mesa-libGL to avoid conflict ln -s %{_libdir}/libGLX_mesa.so.0 %{buildroot}%{_libdir}/libGLX_indirect.so.0 %else ln -s libGLX_nvidia.so.%{version} %{buildroot}%{_libdir}/libGLX_indirect.so.0 # ld.so.conf.d file install -m 0755 -d %{buildroot}%{_sysconfdir}/ld.so.conf.d/ echo -e "%{_nvidia_libdir} \n" > %{buildroot}%{_sysconfdir}/ld.so.conf.d/nvidia-%{_lib}.conf %endif I assume at some point this change will filter through into the mesa package in RHEL at which point we may have to handle it similarly. |
|
The fallback is either via the libGLX_indirect.so.0 link or the __GLX_VENDOR_LIBRARY_NAME environment variable. I propose to use the latter approach for ElRepo for the reasons mentioned above. Patch attached. |
|
Given that at some point in the future, upstream is likely to symlink libGLX_indirect.so.0 against mesa, I'm inclined to agree exporting __GLX_VENDOR_LIBRARY_NAME is a cleaner solution. I'll queue for inclusion in the next release. |
|
I've reverted the original fix in 384.59-1 and applied the fix to export _GLX_VENDOR_LIBRARY_NAME in 384.69-2 Packages should be built and released later today. Closing as fixed. Please reopen / refile if further issues. Thanks to all |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-01-27 16:54 | jchan | New Issue | |
2017-01-27 16:54 | jchan | Status | new => assigned |
2017-01-27 16:54 | jchan | Assigned To | => pperry |
2017-01-27 22:41 | pperry | Note Added: 0005056 | |
2017-01-27 22:43 | pperry | Relationship added | duplicate of 0000713 |
2017-01-27 23:09 | pperry | Note Added: 0005057 | |
2017-01-28 00:27 | pperry | Note Added: 0005058 | |
2017-01-30 11:25 | jchan | Note Added: 0005059 | |
2017-05-19 06:48 | osmiza | Note Added: 0005213 | |
2017-05-19 12:49 | pperry | Note Added: 0005214 | |
2017-06-02 15:57 | jchan | Note Added: 0005247 | |
2017-06-02 16:18 | pperry | Note Added: 0005248 | |
2017-07-27 15:17 | pperry | Note Added: 0005349 | |
2017-07-27 15:18 | pperry | Status | assigned => resolved |
2017-07-27 15:18 | pperry | Resolution | open => fixed |
2017-07-27 15:21 | pperry | Status | resolved => assigned |
2017-08-13 15:39 | rg | Note Added: 0005386 | |
2017-08-13 15:51 | pperry | Note Added: 0005387 | |
2017-08-13 16:32 | pperry | Note Added: 0005388 | |
2017-08-13 17:14 | rg | File Added: libGLX_indirect.diff | |
2017-08-13 17:39 | rg | Note Added: 0005390 | |
2017-08-14 00:16 | pperry | Note Added: 0005391 | |
2017-09-10 07:59 | pperry | Note Added: 0005472 | |
2017-09-10 07:59 | pperry | Status | assigned => resolved |