View Issue Details

IDProjectCategoryView StatusLast Update
0000610channel: elrepo/el7nvidia-x11-drvpublic2016-07-14 13:58
Reporterprefect Assigned Topperry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Summary0000610: nVidia driver can't do remote OpenGL anymore
DescriptionWith the updated X server from 7.2 (CentOS 7.1 CR), indirect GLX is disabled by default. This doesn't combine well with the nvidia driver.

The problem seen by the user is that they can no longer ssh to another machine and run an OpenGL application, which was previously a commonly used feature by us.

Output of glxinfo:
libGL error: failed to load driver: swrast
X Error of failed request: BadValue (integer parameter out of range for operation)
  Major opcode of failed request: 153 (GLX)
  Minor opcode of failed request: 3 (X_GLXCreateContext)
  Value in failed request: 0x0
  Serial number of failed request: 27
  Current serial number in output stream: 30

You can also see this behaviour by using the Mesa client libGL:

LD_LIBRARY_PATH=/usr/lib64 glxinfo
name of display: :0
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
  Major opcode of failed request: 153 (GLX)
  Minor opcode of failed request: 6 (X_GLXIsDirect)
  Serial number of failed request: 46
  Current serial number in output stream: 45

With nouveau no such problem exists, presumably because it's doing software rendering?

Reenabling iglx in the X server restores functionality, but that's not obviously trivial to implement with gdm (at least not to me).

Other than enabling iglx via a slightly grim wrapper script for Xorg, any suggestions as to a workaround?
Additional Informationkernel-3.10.0-327.el7.x86_64
nvidia-x11-drv-352.63-1.el7.elrepo.x86_64
xorg-x11-server-Xorg-1.17.2-10.el7.x86_64
TagsNo tags attached.
Reported upstream

Activities

pperry

2015-12-09 13:02

administrator   ~0004591

If I understand correctly, this appears to be a result of the updated Xorg server (1.17.2) in EL7.2.

I note the following in the nvidia documentation:

ftp://download.nvidia.com/XFree86/Linux-x86_64/352.63/README/xconfigoptions.html

Option "AllowIndirectGLXProtocol" "boolean"

    There are two ways that GLX applications can render on an X screen: direct and indirect. Direct rendering is generally faster and more featureful, but indirect rendering may be used in more configurations. Direct rendering requires that the application be running on the same machine as the X server, and that the OpenGL library have sufficient permissions to access the kernel driver. Indirect rendering works with remote X11 connections as well as unprivileged clients like those in a chroot with no access to device nodes.

    For those who wish to disable the use of indirect GLX protocol on a given X screen, setting the "AllowIndirectGLXProtocol" to a true value will cause GLX CreateContext requests with the direct parameter set to False to fail with a BadValue error.

    Starting with X.Org server 1.16, there are also command-line switches to enable or disable use of indirect GLX contexts. -iglx disables use of indirect GLX protocol, and +iglx enables use of indirect GLX protocol. +iglx is the default in server 1.16, but as of this writing it is expected that in the next major release -iglx will be the default.

    The NVIDIA GLX implementation will prohibit creation of indirect GLX contexts if the AllowIndirectGLXProtocol option is set to False, or the -iglx switch was passed to the X server (X.Org server 1.16 or higher), or the X server defaulted to '-iglx'.

    Default: enabled (indirect protocol is allowed, unless disabled by the server).



So the feature appears to be behaving as described in the documentation, hence not a bug in our packaging of the nvidia driver.

prefect

2015-12-09 14:27

reporter   ~0004592

Yes, I think you're entirely right. Your packaging is just grand, and I should be taking this up with Redhat and nvidia.

I think I was just confused by nouveau and the VMware driver not suffering from this issue, but that still makes it an nvidia driver issue and not your packaging.

pperry

2015-12-09 15:23

administrator   ~0004593

OK, marking as Not A Bug as I'm agreed this is due to updated Xorg Server defaults. The workaround would appear to be to start Xorg with -iglx

pperry

2016-07-14 13:58

administrator   ~0004819

This bug was filed against RHEL7, but there was a recent xorg-x11-server update to RHEL6.8 that addressed this issue including workarounds so I'm including it here for reference. I don't know if this issue has been similarly addressed in RHEL7.

https://rhn.redhat.com/errata/RHBA-2016-1402.html


Updated xorg-x11-server packages that fix one bug are now available for Red Hat
Enterprise Linux 6.

X.Org is an open source implementation of the X Window System. It provides the
basic low-level functionality that full-fledged graphical user interfaces are
designed upon.

This update fixes the following bug:

* The X server update in Red Hat Enterprise Linux 6.8 included two behavior
changes relative to version 6.7. By default, the X server did not listen for
connections over TCP, and refused indirect GLX contexts. This update restores
the defaults to those of version 6.7. In addition, it adds the "+iglx", "-iglx"
options to explicitly control indirect GLX context support: "+iglx" to allow
creating indirect GLX contexts, "-iglx" to disallow it. The default behavior is
to allow creating indirect GLX contexts.

To control indirect GLX contexts when using a display manager like GDM
that does not allow arbitrary modification to the X server's command
line, use the "AllowIndirectGLX" option in the ServerFlags section of
xorg.conf:

Section "ServerFlags"
Option "AllowIndirectGLX" "on" # or "off"
EndSection

Issue History

Date Modified Username Field Change
2015-12-09 09:28 prefect New Issue
2015-12-09 09:28 prefect Status new => assigned
2015-12-09 09:28 prefect Assigned To => pperry
2015-12-09 13:02 pperry Note Added: 0004591
2015-12-09 14:27 prefect Note Added: 0004592
2015-12-09 15:23 pperry Note Added: 0004593
2015-12-09 15:23 pperry Status assigned => resolved
2015-12-09 15:23 pperry Resolution open => no change required
2016-07-14 13:58 pperry Note Added: 0004819