Solved Xorg crash - GLSL compile failure

Hi all,

I've got an new install of FreeBSD (that I just upgraded to the latest 14.1-RELEASE-p5) and all configuration went well until it came to configuring my desktop environment. I can start an X session fine (using startx) and fluxbox loads ok. However when I try to open a rxvt terminal X (version 1.21.1.13) promptly crashes.

This happens every time so I was able to capture a log:

Code:
for translation, using default messages.
unable to connect to the rxvt-unicode daemon: Connection refused
Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES

Program source:
#version 130
#ifdef GL_ES
precision mediump float;
#endif
#define RepeatNone                         0
#define RepeatNormal                     1
#define RepeatPad                        2
#define RepeatReflect                    3
#define RepeatFix                        10
uniform int             source_repeat_mode;
uniform int             mask_repeat_mode;
vec2 rel_tex_coord(vec2 texture, vec4 wh, int repeat)
{
    vec2 rel_tex;
    rel_tex = texture * wh.xy;
    if (repeat == RepeatFix + RepeatNone)
        return rel_tex;
    else if (repeat == RepeatFix + RepeatNormal)
        rel_tex = floor(rel_tex) + (fract(rel_tex) / wh.xy);
    else if (repeat == RepeatFix + RepeatPad) {
        if (rel_tex.x >= 1.0)
            rel_tex.x = 1.0 - wh.z * wh.x / 2.;
        else if (rel_tex.x < 0.0)
            rel_tex.x = 0.0;
        if (rel_tex.y >= 1.0)
            rel_tex.y = 1.0 - wh.w * wh.y / 2.;
        else if (rel_tex.y < 0.0)
            rel_tex.y = 0.0;
        rel_tex = rel_tex / wh.xy;
    } else if (repeat == RepeatFix + RepeatReflect) {
        if ((1.0 - mod(abs(floor(rel_tex.x)), 2.0)) < 0.001)
(EE)
Fatal server error:
(EE) GLSL compile failure
(EE)
(EE)
Please consult the The X.Org Foundation support
     at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
X connection to :0 broken (explicit kill or server shutdown).
Fluxbox: XIOError: lost connection to display.
X connection to :0 broken (explicit kill or server shutdown).
X connection to :0 broken (explicit kill or server shutdown).
X connection to :0 broken (explicit kill or server shutdown).
X connection to :0 broken (explicit kill or server shutdown).
X connection to :0 broken (explicit kill or server shutdown).
urxvt: X connection to ':0.0' broken, unable to recover, exiting.
protocol error: unexpected eof from server.
xinit: connection to X server lost

I notice the error "Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES" and was wondering if something went wrong during the package updates and some packages didn't get properly updated?

Anyone seen this before and can recommend a fix? I found this forum post and I can confirm the workaround of adding Option "AccelMethod" "none" has allowed me to use my desktop and terminals, but the expense of no acceleration.
 
i used rxvt for years but got fed up with the font rendering
so i switched to Alacritty which works really well on Freebsd


Alacritty has much better font render and a toml config file
which is so much better than using a .Xresources file to configure the terminal

you also have live updating of the config file
so when you make a change its applied instantly

with rxvt you have to close the terminal after editing the Xresources
and then use xrdb to apply the changes ( long time since i used rxvt, so i dont know if there is an easier method now )

Code:
xrdb ~/.Xresources

if rxvt is giving you some issue might be having a look at alacritty

alacritty install

Code:
sudo pkg install alacritty

my alacritty config

 
Can you run rxvt via:

$ LIBGL_ALWAYS_SOFTWARE=1 rxvt

A terminal emulator doesn't need hardware acceleration so it should be fine without. The software fallback of LLVMpipe supports OpenGL 4.x+ and latest GLSL.

(Also, nothing in that fragment shader looks to need GLSL 1.30 either. So perhaps you could log a bug ticket upstream for them to fix the needless overconsumption of API features? They can confirm via the GL docs, i.e here)

Edit: Unless the Xserver itself is crashing? I can't quite tell if that is the case or if the session is simply ending because fluxbox or rxvt is terminating.
 
From which version, exactly?
14.1-RELEASE-p3 AFAIR

i used rxvt for years but got fed up with the font rendering
so i switched to Alacritty which works really well on Freebsd
What is wrong with the font rendering? I've used it for years and never found the font rendering a problem. The other is that is supports pseudo-transparency. Very few terminals support that nowadays. I had a look at the Alacritty website but see no mention of pseudo-transparency support.

Edit: Unless the Xserver itself is crashing? I can't quite tell if that is the case or if the session is simply ending because fluxbox or rxvt is terminating.
To me it seems like the X server itself is crashing, at least based on this line from the error message above:
Code:
(EE) Server terminated with error (1). Closing log file.

I will try running rxvt with LIBGL_ALWAYS_SOFTWARE=1 and see what happens.
 
I was sure i had seen something about setting the opacity in Alacritty

turns out i was right,
i did a video about setting the opacity in Alacritty and Emacs

 
I was sure i had seen something about setting the opacity in Alacritty

turns out i was right,
i did a video about setting the opacity in Alacritty and Emacs

Nice, however I didn't see what happens when you overlay a transparent terminal over another terminal (or application) in the background? From the video I only saw one terminal window used for testing.

One of the reasons I avoid "real transparency" like the plague is because I set my terminals to be translucent so I can see the background image I set, not whatever other app is underneath the terminal window. Plus it becomes a struggle to clearly read text on your terminal if there is text underneath, hence my preference for "pseudo-transparency", not to mention it is usually much easier to set up, needing only two command line options.

I will try running rxvt with LIBGL_ALWAYS_SOFTWARE=1 and see what happens.

Alas this did not work. urxvt still crashes regardless of the setting.
 
Alas this did not work. urxvt still crashes regardless of the setting.
Darn.

An awkward workaround would be to run Xephyr (or Xnest) and run urxvt in there on your Xorg session.
I used to have to do that with LibreOffice. That used to take down Xorg for various reasons on my older Intel GPU.

(what we are probably seeing is a little bit of bitrot in the driver layers).
 
Is this with i915kms driver?
Yes it is.

Darn.

An awkward workaround would be to run Xephyr (or Xnest) and run urxvt in there on your Xorg session.
I used to have to do that with LibreOffice. That used to take down Xorg for various reasons on my older Intel GPU.

(what we are probably seeing is a little bit of bitrot in the driver layers).

Hmm, its a bit of a kludge, also I don't know if any other software will cause a crash. I just hit the issue with urxvt because it is the first app I opened after the upgrade. Possibly some other software will also crash but I have not opened them to try yet.

Also I don't know if this helps deduce what has happened but I found out that if I disable pseudo-transparency Xorg doesn't crash. So removing "-tr -sh 40" from the urxvt command results in no crash. Its a bit odd as to my knowledge urxvt does not use GL for transparency, but just uses the root X window background (i.e my wallpaper) to manually redraw the tinted background behind the terminal window.
 
Perhaps you can try isolating the broken parts.
In the intel(4) and modesetting(4) Xorg drivers (not sure which you are using), there is the AccelMethod option. Try setting this to "none". Obviously not ideal but may help to work out which part is broken.
 
Perhaps you can try isolating the broken parts.
In the intel(4) and modesetting(4) Xorg drivers (not sure which you are using), there is the AccelMethod option. Try setting this to "none". Obviously not ideal but may help to work out which part is broken.

Yes that was one of the things I did (mentioned in my first post). It does fix the crashing issue insofar as it disabled acceleration completely. It is what I am using in the interim to carry on with my laptop. I don't know what performance impact that will have with other apps (especially ones that render 3D or video) which is why I wanted to see if there was something that would allow me to keep HW acceleration enabled.
 
Yes that was one of the things I did (mentioned in my first post). It does fix the crashing issue insofar as it disabled acceleration completely. It is what I am using in the interim to carry on with my laptop. I don't know what performance impact that will have with other apps (especially ones that render 3D or video) which is why I wanted to see if there was something that would allow me to keep HW acceleration enabled.
Ah right, so you did, my bad.

If you are using the intel(4) driver, there are more options for DRI and AccelMethod options for you to have a play with. But I am not sure how well maintained the usermode driver is. It may need to be installed from ports separately too.
 
Good you don't need it as it's only for very old hardware.
Can you try without the i915kms driver.

Edit:
also attach the Xorg.0.log and glxinfo

I can't reproduce your issue neither with modesetting 25.2 driver or the intel

urxvt -depth 32 -bg rgba:0000/0000/0000/4444 -fg "[80]pink"


If i try to enable the fake transparency using:
urxvt*transparent: true
urxvt*shading: 30

Instead of alpha channel
urxvt*depth: 32
urxvt*background: rgba:0000/0000/0000/4444

Then i got only error about urxvt error of failed request: BadMatch and RenderBadPicture but the X doesn't crash like yours.


~/.Xdefaults

Code:
#urxvt*inheritPixmap: true
#urxvt*transparent: true  
#urxvt*shading: 30

urxvt*depth: 32
urxvt*background: rgba:0000/0000/0000/7777
urxvt*foreground: green
 
Hello Unixnut,
today, I had the exact same problem with Xorg, with the same error messages, but on Linux (Debian 12).
My system also uses the Intel i915 graphics driver module.

The default (unset) AccelMethod configuration caused my Xorg server to crash every time I've tried to - for example - forward an email in Thunderbird. According to this page:
https://wiki.archlinux.org/title/Intel_graphics#AccelMethod
the i915 driver supports, beside others, the "sna" and "uxa" acceleration, and "sna" should be the default. But it seems that Xorg did use another acceleration method as default, because after I explicit did set the AccelMethod to "sna" in xorg.conf, my problem was solved!

So, if setting the AccelMethod to "none" did help you, you perhaps should give the "sna" and "uxa" options a try... :)
Hope I could help....
Greetings!
 
Sorry to come up with it again, but it may be relevant which "i915kms" you actually have been using, so can you give the output of:
pkg info `pkg info -g 'drm-*-kmod'`
 
Yes that was one of the things I did (mentioned in my first post). It does fix the crashing issue insofar as it disabled acceleration completely. It is what I am using in the interim to carry on with my laptop. I don't know what performance impact that will have with other apps (especially ones that render 3D or video) which is why I wanted to see if there was something that would allow me to keep HW acceleration enabled.
Well, after a couple of months of not having acceleration the crashes have gone away. However watching videos is not really feasible and some applications (like KiCAD) are really sluggish and consume loads of CPU power when rendering.

It seems some "normal" (i.e. not games or graphics orientated programs) now rely on acceleration so it would be nice to get it working again on my system.

Sorry to come up with it again, but it may be relevant which "i915kms" you actually have been using, so can you give the output of:
pkg info `pkg info -g 'drm-*-kmod'`
Code:
drm-61-kmod-6.1.92
Name           : drm-61-kmod
Version        : 6.1.92
Installed on   : Sat Oct 12 14:13:04 2024 CEST
Origin         : graphics/drm-61-kmod
Architecture   : FreeBSD:14:amd64
Prefix         : /usr/local
Categories     : kld graphics
Licenses       : MIT and GPLv2 and BSD2CLAUSE
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/freebsd/drm-kmod/
Comment        : DRM drivers modules
Annotations    :
    FreeBSD_version: 1401000
    build_timestamp: 2024-10-01T01:56:24+0000
    built_by       : poudriere-git-3.4.2
    port_checkout_unclean: no
    port_git_hash  : 854c13714
    ports_top_checkout_unclean: no
    ports_top_git_hash: 2f11ca479
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 17.0MiB
Description    :
amdgpu, i915, and radeon DRM drivers modules.
Currently corresponding to Linux 6.1 DRM.
This version is for FreeBSD 14-STABLE 1400508
and above.


So, if setting the AccelMethod to "none" did help you, you perhaps should give the "sna" and "uxa" options a try... :)
Hope I could help....
Greetings!
Oh, yes AccelMethod "none" has fixed the issue for me. lets give it a try with the two options and see what happens...
 
Hello Unixnut,
today, I had the exact same problem with Xorg, with the same error messages, but on Linux (Debian 12).
My system also uses the Intel i915 graphics driver module.

The default (unset) AccelMethod configuration caused my Xorg server to crash every time I've tried to - for example - forward an email in Thunderbird. According to this page:
https://wiki.archlinux.org/title/Intel_graphics#AccelMethod
the i915 driver supports, beside others, the "sna" and "uxa" acceleration, and "sna" should be the default. But it seems that Xorg did use another acceleration method as default, because after I explicit did set the AccelMethod to "sna" in xorg.conf, my problem was solved!

So, if setting the AccelMethod to "none" did help you, you perhaps should give the "sna" and "uxa" options a try... :)
Hope I could help....
Greetings!
Yep, It looks like this solves it for me.

If I set AccelMethod to "none", "sna" or "uxa" then I don't get any problems when I open the terminal. However if I leave AccelMethod commented out (i.e. leave Xorg to pick the default) I get Xorg crashing again.

From your recommendation I've set it to "sna", and so far things are looking good :)

EDIT:

From your link it seems there is a third option "blt". I tried with that one too and things worked fine. Whatever the default is for Xorg on this version, it causes the crash (unless it is not picking a default, which might be causing the issue?)
 
Back
Top