I have a CentOS 7.9 system on which X2Go was previously working perfectly, but which is now broken. It broke after a typical yum update but I am not sure what changed to break things and I would like some help debugging and resolving this issue. I should mention that as part of my troubleshooting I have begun using NVIDIA kmod drivers from the ELRepo instead of ones installed from NVIDIA's .run file.
The behavior I'm seeing in every failed connection produces the following log entries. The system has both XFCE and MATE installed and both produce the same output.
Oct 19 10:21:29 c113256 /usr/bin/x2goruncommand: launching session with Xsession-x2go mechanism, using STARTUP="mate-session" Oct 19 10:21:29 c113256 /usr/bin/x2goruncommand: dbus wrapper available as /usr/bin/dbus-run-session Oct 19 10:21:30 c113256 kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c4000-0x000c7fff window] Oct 19 10:21:30 c113256 kernel: caller os_map_kernel_space.part.6+0x95/0xc0 [nvidia] mapping multiple BARs Oct 19 10:21:31 c113256 kernel: x2goagent[58376]: segfault at 48 ip 0000555fbee349ab sp 00007ffe380702a0 error 4 in nxagent[555fbecd6000+439000] Oct 19 10:21:31 c113256 abrt-hook-ccpp: Process 58376 (nxagent) of user 1001 killed by SIGSEGV - dumping core
Interestingly, x2goagent does not segfault if I have the X2Go client run /bin/xclock. The window opens without issue. /bin/firefox fails. /bin/glxgears also fails. Is this related to GL/GLX? How can I obtain more detailed information?
Thank you!
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
Well, yum history shows you the list of updated packages.
However, nxagent should not come into touch with the nvidia stuff as it is not using the GPU of your server. So I guess some software inside your mate session is using OpenGL and trying to achieve that via nvidia's libGL. I suggest to try uninstalling the nvidia driver and see if that works. Alternative you may reinstall mesa.
Generally you need to use software rendering. There's a workaround how to achieve that for single applications on the x2go wiki. It might get complicated to use that already for the session startup.
Thinking about it leads to this simple test: start an x2go session with xterm instead of xclock. in that xterm start glxgears and see if the session crashes. If you, try another xterm session and run
__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxgears.
Uli
Hi Ulrich,
Thanks for the prompt response, I really appreciate it.
I unfortunately require the proprietary nvidia driver as this system, a GPU processing host, runs a few pieces of CUDA software. My other requirement is the ability to render WebGL content in Firefox for use with one of the tools.
The yum history is there - what I should have said is that I do not understand which packages might be involved. There was a kernel update after which I had to reinstall the NVIDIA drivers (from the .run file). After doing so, I found I could not render WebGL in Firefox (running in an X2Go MATE desktop session). I found that my x2go sessions were using the OpenGL Mesa GLX Indirect renderer, as reported by glxinfo, and believed that to be the cause of the WebGL problem since it requires direct rendering and a newer version of OpenGL than the Mesa GLX Indirect renderer supports. This caused me to believe I needed to render OpenGL with the nvidia driver.
I switched to the ELRepo kmod-nvidia package which produced the x2goagent errors, likely because Xorg was running with the nvidia driver. That's when I made my original post.
I've subsequently replaced the ELRepo driver with the NVIDIA driver from the .run file again. Now the GPUs are accessible and I can connect to X2Go but WebGL still doesn't function. Xorg is running with the nouveau driver according to Xorg.0.log and glxinfo reports "direct rendering: No". The Firefox about:support page shows errors like:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Any idea how I can get WebGL rendered in an X2Go session again? I would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all possible.
On Tue, Oct 19, 2021 at 2:27 PM Ulrich Sibiller <uli42@gmx.de> wrote:
Well, yum history shows you the list of updated packages.
However, nxagent should not come into touch with the nvidia stuff as it is not using the GPU of your server. So I guess some software inside your mate session is using OpenGL and trying to achieve that via nvidia's libGL. I suggest to try uninstalling the nvidia driver and see if that works. Alternative you may reinstall mesa.
Generally you need to use software rendering. There's a workaround how to achieve that for single applications on the x2go wiki. It might get complicated to use that already for the session startup.
Thinking about it leads to this simple test: start an x2go session with xterm instead of xclock. in that xterm start glxgears and see if the session crashes. If you, try another xterm session and run
__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxgears.
Uli
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
On Wed, Oct 20, 2021 at 2:48 AM Eric Shell <eshell@ucsc.edu> wrote:
I unfortunately require the proprietary nvidia driver as this system, a GPU processing host, runs a few pieces of CUDA software. My other requirement is the ability to render WebGL content in Firefox for use with one of the tools.
Unfortunately I have used such a setup.
The yum history is there - what I should have said is that I do not understand which packages might be involved. There was a kernel update after which I had to reinstall the NVIDIA drivers (from the .run file). After doing so, I found I could not render WebGL in Firefox (running in an X2Go MATE desktop session). I found that my x2go sessions were using the OpenGL Mesa GLX Indirect renderer, as reported by glxinfo, and believed that to be the cause of the WebGL problem since it requires direct rendering and a newer version of OpenGL than the Mesa GLX Indirect renderer supports. This caused me to believe I needed to render OpenGL with the nvidia driver.
Did you reinstall the same nvidia drivers or a newer version?
IIRC there once was the necessity to chmod /dev/nvidia or similar to make it available to all users. Not sure if that's still required.
I switched to the ELRepo kmod-nvidia package which produced the x2goagent errors, likely because Xorg was running with the nvidia driver. That's when I made my original post.
I've subsequently replaced the ELRepo driver with the NVIDIA driver from the .run file again. Now the GPUs are accessible and I can connect to X2Go but WebGL still doesn't function. Xorg is running with the nouveau driver according to Xorg.0.log and glxinfo reports "direct rendering: No". The Firefox about:support page shows errors like:
Just to be sure: are you connecting to the local X server (a so called shadow session) or are you starting a NEW mate desktop in addition to X server?
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Does this call work with glxinfo/glxgears?
Any idea how I can get WebGL rendered in an X2Go session again? I would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all possible.
I am a bit puzzled about that blacklist entry. Maybe that is modifiable in about:config. I have checked my firefox88 and it does NOT seem to have this blacklist entry in about:config.
Also check/disable the hardware acceleration setting in firefox.
Uli
Did you reinstall the same nvidia drivers or a newer version?
Right now I'm again running the original drivers (460.73.01) installed from the .run file.
IIRC there once was the necessity to chmod /dev/nvidia or similar to make it available to all users. Not sure if that's still required.
The permissions look correct. There are /dev/nvidia0 and /dev/nvidia1 devices for the 2 GPUs:
# ll /dev/nvidia* crw-rw-rw-. 1 root root 195, 0 Oct 19 09:58 /dev/nvidia0
Just to be sure: are you connecting to the local X server (a so called shadow session) or are you starting a NEW mate desktop in addition to X server?
I don't think so but how can I tell? I am not connecting with X2Go/X11 Desktop Sharing if that's what opens a shadow session, but rather starting a MATE session.
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Does this call work with glxinfo/glxgears?
Yes, it does. glxgears runs without crashing the session and glxinfo reports it is using direct rendering. It appears to be using my client's (a VM) X server for OpenGL rendering, is that right?
$ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxinfo ... OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits) OpenGL version string: 2.1 Mesa 18.3.4 OpenGL shading language version string: 1.20
Any idea how I can get WebGL rendered in an X2Go session again? I would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all possible.
I am a bit puzzled about that blacklist entry. Maybe that is modifiable in about:config. I have checked my firefox88 and it does NOT seem to have this blacklist entry in about:config.
Also check/disable the hardware acceleration setting in firefox.
I tried setting webgl.force-enabled to true and got different output from about:support:
WebGL creation failed:
- tryNativeGL
- Exhausted GL driver options.
I've tried toggling hardware acceleration on/off but it doesn't seem to make a difference.
Uli
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
Well, as said before I do not have any Nvidia hardware. But today I played a bit with that stuff with Firefox 78.7.0-esr on Debian wiht Intel graphics and I see the same errors you see inside NX. So maybe this is not all linked to nvidia but simply firefox failing some checks in an NX session. firefox does not even load libGL here. Investigating further... Uli
On Thu, Oct 21, 2021 at 5:54 PM Eric Shell <eshell@ucsc.edu> wrote:
Did you reinstall the same nvidia drivers or a newer version?
Right now I'm again running the original drivers (460.73.01) installed from the .run file.
IIRC there once was the necessity to chmod /dev/nvidia or similar to make it available to all users. Not sure if that's still required.
The permissions look correct. There are /dev/nvidia0 and /dev/nvidia1 devices for the 2 GPUs:
# ll /dev/nvidia* crw-rw-rw-. 1 root root 195, 0 Oct 19 09:58 /dev/nvidia0
Just to be sure: are you connecting to the local X server (a so called shadow session) or are you starting a NEW mate desktop in addition to X server?
I don't think so but how can I tell? I am not connecting with X2Go/X11 Desktop Sharing if that's what opens a shadow session, but rather starting a MATE session.
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Does this call work with glxinfo/glxgears?
Yes, it does. glxgears runs without crashing the session and glxinfo reports it is using direct rendering. It appears to be using my client's (a VM) X server for OpenGL rendering, is that right?
$ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxinfo ... OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits) OpenGL version string: 2.1 Mesa 18.3.4 OpenGL shading language version string: 1.20
Any idea how I can get WebGL rendered in an X2Go session again? I would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all possible.
I am a bit puzzled about that blacklist entry. Maybe that is modifiable in about:config. I have checked my firefox88 and it does NOT seem to have this blacklist entry in about:config.
Also check/disable the hardware acceleration setting in firefox.
I tried setting webgl.force-enabled to true and got different output from about:support:
WebGL creation failed:
- tryNativeGL
- Exhausted GL driver options.
I've tried toggling hardware acceleration on/off but it doesn't seem to make a difference.
Uli
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
Hi Ulrich,
Thank you for continuing to look into this.
I ran into another problem with GLX today, with a tool called chimerax which requires GLX 1.4 or greater. I read the page on getting GLX 1.4 working on the wiki ( https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround) and I was wondering if it meant that the wrappers do not work with the NVIDIA drivers. I take it that means that if an application won't run with the
__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 <your application>
workaround, there's not much else to try?
On Sat, Oct 23, 2021 at 10:49 AM Ulrich Sibiller <uli42@gmx.de> wrote:
Well, as said before I do not have any Nvidia hardware. But today I played a bit with that stuff with Firefox 78.7.0-esr on Debian wiht Intel graphics and I see the same errors you see inside NX. So maybe this is not all linked to nvidia but simply firefox failing some checks in an NX session. firefox does not even load libGL here. Investigating further... Uli
Did you reinstall the same nvidia drivers or a newer version?
Right now I'm again running the original drivers (460.73.01) installed from the .run file.
IIRC there once was the necessity to chmod /dev/nvidia or similar to make it available to all users. Not sure if that's still required.
The permissions look correct. There are /dev/nvidia0 and /dev/nvidia1 devices for the 2 GPUs:
# ll /dev/nvidia* crw-rw-rw-. 1 root root 195, 0 Oct 19 09:58 /dev/nvidia0
Just to be sure: are you connecting to the local X server (a so called shadow session) or are you starting a NEW mate desktop in addition to X server?
I don't think so but how can I tell? I am not connecting with X2Go/X11 Desktop Sharing if that's what opens a shadow session, but rather starting a MATE session.
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Does this call work with glxinfo/glxgears?
Yes, it does. glxgears runs without crashing the session and glxinfo reports it is using direct rendering. It appears to be using my client's (a VM) X server for OpenGL rendering, is that right?
$ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxinfo ... OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits) OpenGL version string: 2.1 Mesa 18.3.4 OpenGL shading language version string: 1.20
Any idea how I can get WebGL rendered in an X2Go session again? I
would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all
On Thu, Oct 21, 2021 at 5:54 PM Eric Shell <eshell@ucsc.edu> wrote: possible.
I am a bit puzzled about that blacklist entry. Maybe that is modifiable in about:config. I have checked my firefox88 and it does NOT seem to have this blacklist entry in about:config.
Also check/disable the hardware acceleration setting in firefox.
I tried setting webgl.force-enabled to true and got different output from about:support:
WebGL creation failed:
- tryNativeGL
- Exhausted GL driver options.
I've tried toggling hardware acceleration on/off but it doesn't seem to make a difference.
Uli
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
I am not sure. Did you try to run chimerax with the workaround?
On Mon, Oct 25, 2021 at 8:57 PM Eric Shell <eshell@ucsc.edu> wrote:
Hi Ulrich,
Thank you for continuing to look into this.
I ran into another problem with GLX today, with a tool called chimerax which requires GLX 1.4 or greater. I read the page on getting GLX 1.4 working on the wiki (https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround) and I was wondering if it meant that the wrappers do not work with the NVIDIA drivers. I take it that means that if an application won't run with the
__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 <your application>
workaround, there's not much else to try?
On Sat, Oct 23, 2021 at 10:49 AM Ulrich Sibiller <uli42@gmx.de> wrote:
Well, as said before I do not have any Nvidia hardware. But today I played a bit with that stuff with Firefox 78.7.0-esr on Debian wiht Intel graphics and I see the same errors you see inside NX. So maybe this is not all linked to nvidia but simply firefox failing some checks in an NX session. firefox does not even load libGL here. Investigating further... Uli
On Thu, Oct 21, 2021 at 5:54 PM Eric Shell <eshell@ucsc.edu> wrote:
Did you reinstall the same nvidia drivers or a newer version?
Right now I'm again running the original drivers (460.73.01) installed from the .run file.
IIRC there once was the necessity to chmod /dev/nvidia or similar to make it available to all users. Not sure if that's still required.
The permissions look correct. There are /dev/nvidia0 and /dev/nvidia1 devices for the 2 GPUs:
# ll /dev/nvidia* crw-rw-rw-. 1 root root 195, 0 Oct 19 09:58 /dev/nvidia0
Just to be sure: are you connecting to the local X server (a so called shadow session) or are you starting a NEW mate desktop in addition to X server?
I don't think so but how can I tell? I am not connecting with X2Go/X11 Desktop Sharing if that's what opens a shadow session, but rather starting a MATE session.
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Does this call work with glxinfo/glxgears?
Yes, it does. glxgears runs without crashing the session and glxinfo reports it is using direct rendering. It appears to be using my client's (a VM) X server for OpenGL rendering, is that right?
$ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxinfo ... OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits) OpenGL version string: 2.1 Mesa 18.3.4 OpenGL shading language version string: 1.20
Any idea how I can get WebGL rendered in an X2Go session again? I would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all possible.
I am a bit puzzled about that blacklist entry. Maybe that is modifiable in about:config. I have checked my firefox88 and it does NOT seem to have this blacklist entry in about:config.
Also check/disable the hardware acceleration setting in firefox.
I tried setting webgl.force-enabled to true and got different output from about:support:
WebGL creation failed:
- tryNativeGL
- Exhausted GL driver options.
I've tried toggling hardware acceleration on/off but it doesn't seem to make a difference.
Uli
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
Yes, it failed with an error about Python not being able to initialize GLX. Unfortunately, I didn't record the error and I will not be able to test it again until later this week.
I will provide an update as soon as I am able.
On Mon, Oct 25, 2021 at 1:53 PM Ulrich Sibiller <uli42@gmx.de> wrote:
I am not sure. Did you try to run chimerax with the workaround?
On Mon, Oct 25, 2021 at 8:57 PM Eric Shell <eshell@ucsc.edu> wrote:
Hi Ulrich,
Thank you for continuing to look into this.
I ran into another problem with GLX today, with a tool called chimerax
which requires GLX 1.4 or greater. I read the page on getting GLX 1.4 working on the wiki ( https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround) and I was wondering if it meant that the wrappers do not work with the NVIDIA drivers. I take it that means that if an application won't run with the
__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 <your application>
workaround, there's not much else to try?
On Sat, Oct 23, 2021 at 10:49 AM Ulrich Sibiller <uli42@gmx.de> wrote:
Well, as said before I do not have any Nvidia hardware. But today I played a bit with that stuff with Firefox 78.7.0-esr on Debian wiht Intel graphics and I see the same errors you see inside NX. So maybe this is not all linked to nvidia but simply firefox failing some checks in an NX session. firefox does not even load libGL here. Investigating further... Uli
On Thu, Oct 21, 2021 at 5:54 PM Eric Shell <eshell@ucsc.edu> wrote:
Did you reinstall the same nvidia drivers or a newer version?
Right now I'm again running the original drivers (460.73.01)
IIRC there once was the necessity to chmod /dev/nvidia or similar to make it available to all users. Not sure if that's still required.
The permissions look correct. There are /dev/nvidia0 and /dev/nvidia1
devices for the 2 GPUs:
# ll /dev/nvidia* crw-rw-rw-. 1 root root 195, 0 Oct 19 09:58 /dev/nvidia0
Just to be sure: are you connecting to the local X server (a so
called
shadow session) or are you starting a NEW mate desktop in addition to X server?
I don't think so but how can I tell? I am not connecting with X2Go/X11 Desktop Sharing if that's what opens a shadow session, but rather starting a MATE session.
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
- Exhausted GL driver options.
Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
WebGL creation failed:
- Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
- Exhausted GL driver options.
Does this call work with glxinfo/glxgears?
Yes, it does. glxgears runs without crashing the session and glxinfo reports it is using direct rendering. It appears to be using my client's (a VM) X server for OpenGL rendering, is that right?
$ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxinfo ... OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits) OpenGL version string: 2.1 Mesa 18.3.4 OpenGL shading language version string: 1.20
Any idea how I can get WebGL rendered in an X2Go session again? I
would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all
installed from the .run file. possible.
I am a bit puzzled about that blacklist entry. Maybe that is modifiable in about:config. I have checked my firefox88 and it does NOT seem to have this blacklist entry in about:config.
Also check/disable the hardware acceleration setting in firefox.
I tried setting webgl.force-enabled to true and got different output from about:support:
WebGL creation failed:
- tryNativeGL
- Exhausted GL driver options.
I've tried toggling hardware acceleration on/off but it doesn't seem to make a difference.
Uli
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
I had something similar a few months ago:
https://lists.x2go.org/pipermail/x2go-user/2021-July/006579.html
Essentially, nvidia taking over libGL. I fixed it with (from the above post):
Thanks Ulrich!
Yes indeed the system was using the libGL of nvidia. I did these steps to recover the system:
yum reinstall libglvnd* mesa*
That fixes most of the symlinks of libGL in /usr/lib64 to again point to
the system's libGL.
Except for this one:
# ll /usr/lib64/libGLX_indirect.so.0 lrwxrwxrwx. 1 root root 26 Jul 1 16:03 /usr/lib64/libGLX_indirect.so.0 -> libGLX_nvidia.so.470.42.01
So I did this:
# cd /usr/lib64 # rm -f libGLX_indirect.so.0 # ln -s libGLX_mesa.so.0.0.0 libGLX_indirect.so.0 # ll /usr/lib64/libGLX_indirect.so.0 lrwxrwxrwx. 1 root root 20 Jul 14 11:43 /usr/lib64/libGLX_indirect.so.0 -> libGLX_mesa.so.0.0.0
Now glxinfo (and firefox) don't crash nxagent!
Not sure of the full implications of manually modifying that symlink.
On Wed, 20 Oct 2021 at 04:36, Eric Shell <eshell@ucsc.edu> wrote:
I have a CentOS 7.9 system on which X2Go was previously working perfectly, but which is now broken. It broke after a typical yum update but I am not sure what changed to break things and I would like some help debugging and resolving this issue. I should mention that as part of my troubleshooting I have begun using NVIDIA kmod drivers from the ELRepo instead of ones installed from NVIDIA's .run file.
The behavior I'm seeing in every failed connection produces the following log entries. The system has both XFCE and MATE installed and both produce the same output.
Oct 19 10:21:29 c113256 /usr/bin/x2goruncommand: launching session with Xsession-x2go mechanism, using STARTUP="mate-session" Oct 19 10:21:29 c113256 /usr/bin/x2goruncommand: dbus wrapper available as /usr/bin/dbus-run-session Oct 19 10:21:30 c113256 kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c4000-0x000c7fff window] Oct 19 10:21:30 c113256 kernel: caller os_map_kernel_space.part.6+0x95/0xc0 [nvidia] mapping multiple BARs Oct 19 10:21:31 c113256 kernel: x2goagent[58376]: segfault at 48 ip 0000555fbee349ab sp 00007ffe380702a0 error 4 in nxagent[555fbecd6000+439000] Oct 19 10:21:31 c113256 abrt-hook-ccpp: Process 58376 (nxagent) of user 1001 killed by SIGSEGV - dumping core
Interestingly, x2goagent does not segfault if I have the X2Go client run /bin/xclock. The window opens without issue. /bin/firefox fails. /bin/glxgears also fails. Is this related to GL/GLX? How can I obtain more detailed information?
Thank you!
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
-- Norman Gaywood, Computer Systems Officer School of Science and Technology University of New England Armidale NSW 2351, Australia
ngaywood@une.edu.au http://turing.une.edu.au/~ngaywood Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062
Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
Hi Norman,
Thank you, I actually read your thread but wasn't sure if it might apply for my situation since I think I need direct rendering.
On Tue, Oct 19, 2021 at 4:21 PM Norman Gaywood <ngaywood@une.edu.au> wrote:
I had something similar a few months ago:
https://lists.x2go.org/pipermail/x2go-user/2021-July/006579.html
Essentially, nvidia taking over libGL. I fixed it with (from the above post):
Thanks Ulrich!
Yes indeed the system was using the libGL of nvidia. I did these steps to recover the system:
yum reinstall libglvnd* mesa*
That fixes most of the symlinks of libGL in /usr/lib64 to again point to
the system's libGL.
Except for this one:
# ll /usr/lib64/libGLX_indirect.so.0 lrwxrwxrwx. 1 root root 26 Jul 1 16:03 /usr/lib64/libGLX_indirect.so.0 -> libGLX_nvidia.so.470.42.01
So I did this:
# cd /usr/lib64 # rm -f libGLX_indirect.so.0 # ln -s libGLX_mesa.so.0.0.0 libGLX_indirect.so.0 # ll /usr/lib64/libGLX_indirect.so.0 lrwxrwxrwx. 1 root root 20 Jul 14 11:43 /usr/lib64/libGLX_indirect.so.0 -> libGLX_mesa.so.0.0.0
Now glxinfo (and firefox) don't crash nxagent!
Not sure of the full implications of manually modifying that symlink.
On Wed, 20 Oct 2021 at 04:36, Eric Shell <eshell@ucsc.edu> wrote:
I have a CentOS 7.9 system on which X2Go was previously working perfectly, but which is now broken. It broke after a typical yum update but I am not sure what changed to break things and I would like some help debugging and resolving this issue. I should mention that as part of my troubleshooting I have begun using NVIDIA kmod drivers from the ELRepo instead of ones installed from NVIDIA's .run file.
The behavior I'm seeing in every failed connection produces the following log entries. The system has both XFCE and MATE installed and both produce the same output.
Oct 19 10:21:29 c113256 /usr/bin/x2goruncommand: launching session with Xsession-x2go mechanism, using STARTUP="mate-session" Oct 19 10:21:29 c113256 /usr/bin/x2goruncommand: dbus wrapper available as /usr/bin/dbus-run-session Oct 19 10:21:30 c113256 kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c4000-0x000c7fff window] Oct 19 10:21:30 c113256 kernel: caller os_map_kernel_space.part.6+0x95/0xc0 [nvidia] mapping multiple BARs Oct 19 10:21:31 c113256 kernel: x2goagent[58376]: segfault at 48 ip 0000555fbee349ab sp 00007ffe380702a0 error 4 in nxagent[555fbecd6000+439000] Oct 19 10:21:31 c113256 abrt-hook-ccpp: Process 58376 (nxagent) of user 1001 killed by SIGSEGV - dumping core
Interestingly, x2goagent does not segfault if I have the X2Go client run /bin/xclock. The window opens without issue. /bin/firefox fails. /bin/glxgears also fails. Is this related to GL/GLX? How can I obtain more detailed information?
Thank you!
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
-- Norman Gaywood, Computer Systems Officer School of Science and Technology University of New England Armidale NSW 2351, Australia
ngaywood@une.edu.au http://turing.une.edu.au/~ngaywood Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062
Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
-- Eric Shell PBSci Technical Staff eshell@ucsc.edu 831 459 4919
-
Eric Shell -
Norman Gaywood -
Ulrich Sibiller