495.46 Xorg SIGSEGV in Fedora 35, only on MSI MPG Trident3, and only for MATE desktop

Graphics / Linux Linux
1

I have 4 systems that are maintained with identical *.rpm complements, differing only in hostname, IP + VPN configuration, and fstab, along with systemd services and crontabs per their intended uses. Of these, 2 are perfectly fine with the new 495.46, both HPs, one of which is the HP Omen on which I’m typing (RTX 2070 MQ), the other being an old Envy used mostly for utility work (backup mgmt, VPN hub) (840M), these days not used for anything graphics except having a console session.

The other 2 are hardware-identical MSI MPG Trident3 systems, model 10SC-215US, each with RTX 2060. On both (and only) these 2 machines, the update to 495.46 via rpmfusion’s packaging results in a reproducible Xorg (1.20.14) crash during login, only when using MATE desktop (1.26). Logging in to any other desktop (GNOME [both Xorg and Wayland], KDE, ICEwm, BlackBox, even Sugar) works fine. It seems that MATE alone tickles some bug not seen with the others.

The previous 495.44 worked without problem. dnf downgrade took them back to 470.74. (I don’t know why rpmfusion doesn’t have 495.44 still in place.) Xorg using the downgraded driver works fine, with MATE login producing no complaint.

I have attempted to upload Xorg.1.log but the composition page here keeps complaining of an unspecified “problem.” The short version is that the end of the log concludes, after noting connected and disconnected DFPs, with this:

[ 61623.460] (EE) Backtrace:
[ 61623.460] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x55f5490583c9]
[ 61623.460] (EE) 1: /lib64/libc.so.6 (__sigaction+0x50) [0x7f06456c2750]
[ 61623.460] (EE) 2: ? (?+0x0) [0x0]
[ 61623.460] (EE) 3: /usr/libexec/Xorg (miGlyphs+0x5ce1) [0x55f548fdaf91]
[ 61623.461] (EE) 4: /usr/libexec/Xorg (present_event_notify+0xa18) [0x55f548fe02e8]
[ 61623.461] (EE) 5: /usr/libexec/Xorg (miGlyphs+0x57d1) [0x55f548fdaa81]
[ 61623.461] (EE) 6: /usr/libexec/Xorg (miPutImage+0x1570) [0x55f548ee82f7]
[ 61623.461] (EE) 7: /lib64/libc.so.6 (__libc_start_call_main+0x80) [0x7f06456ad560]
[ 61623.461] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0x7c) [0x7f06456ad60c]
[ 61623.461] (EE) 9: /usr/libexec/Xorg (_start+0x25) [0x55f548ee8695]
[ 61623.461] (EE) Segmentation fault at address 0x0
Fatal server error:
[ 61623.461] (EE) Caught signal 11 (Segmentation fault). Server aborting

Happens every time. The attempt to have ABRT carry out a full report was not useful, concluding with a comment about “no significant information” in what it found.

For the time being, I can continue to use these with 470.74, or I can upgrade again to 495.46 if there is some specific test worth doing – most work on these MSIs is done remotely with VNC + VGL anyhow. Any thoughts on why only MATE, and only these 2 MSIs, have problems with 495.46 would be welcome.

2

For what it’s worth I’ve had a user report what seem to be the same issue with MATE on Gentoo (where 495.44 works and 495.46 doesn’t with a similar looking backtrace, not that it had debug symbols so I only seen it had Xorg and libc.so).

Not that I have more useful info to give, just to say I don’t think it’s distro-specific.

3

Having same issue. Fedora 35, mate desktop. After driver upgrade, login session crashes immediately.

4

A small addition. fedora-nvidia repo at Nvidia driver, CUDA tools and libraries – negativo17.org still has 495.44 driver. I installed it and the system is back to working state. You need to install this specific version, though, since this repo already has 495.46 version and it will be installed by default.

5

Same issue here with Fedora 35 MATE and GT 1030 with the nvidia drivers installed from negativo’s repo.
With 495.46 Xorg always crashes when trying to login and goes back to the login page. Tried with 2-3 recent kernels, always same result.
Downgrading to 495.44 works as usual without issues.
Another report of what might be the same issue: X Server 1.21.1.1 crash on startx with nvidia driver 495.46

6

Hello,

i just filled an issue on the Mate Desktop github.

https://github.com/mate-desktop/mate-desktop/issues/505

1 Like
7

Closing the loop over here,

Can you check whether this is the issue you’re seeing?

8

My stack trace at the top does include “present_event_notify” so it would seem that this is the problem. What confuses me, however, is that my HP Omen is not affected by this problem. I run MATE here as well.

Oh, now, hang on, wait just one darn second…

AHA!

dconf read /org/mate/desktop/session/required-components/windowmanager

Normally says “marco.”

I use compiz on my main machine, not marco. But I had never configured myself on the MSIs to stop using marco, because they’re kinda special case and largely remote use only (as I mentioned above, VNC + VGL). On the MSIs, I just now changed marco to compiz-manager, which is a wrapper script that does startup checks for necessary sanity, and poof no more crash of Xorg. Evidently compiz does not use “present.”

So, 2 things:

  • Xorg needs a patch, sure, to avoid a crash when the window manager uses “present.”
  • It appears that marco alone uses it. If e.g. gnome-shell used it, Xorg would die in GNOME, too, but doesn’t. compiz must not use it.

Has this problem arisen because 495.46 has new support for “present” so that marco inadvertently finds it and tickles the bug?

1 Like
9

Same issue for me on Fedora 35, MATE, GTX 1070. When I log in black screen for a few seconds, then logs out and locks up the machine.

Did the following to fix:

  1. Followed the 4 steps in this question How can I make Compiz work with MATE 1.6? - Ask Ubuntu
  2. I could now log in without crashing, but borders were missing from windows.
  3. dnf install -y compiz compiz-manager
  4. Login again and seems to be working as normal.
10

This Nvidia driver fails on Debian Bullseye 11.2, with the Mate Desktop.

11

I’m getting the impression this issue may get fixed from Xorg’s side instead (ultimately it’s not nvidia-drivers that are segfaulting, but Xorg while using it which may indicate something that used to work by accident).

It was just added to the next milestone, so perhaps next Xorg version.

12

On Fedora the issue is fixed with xorg-x11-server-1.20.14-3. Nvidia driver 495.46 is now working fine with MATE DE.

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.