Xorg with EVDI can't start with Mesa 21.0

[Jonathan Kamens]

As I indicated in a bug report I filed earlier today, https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1920059, evdi-dkms can no longer compile the evdi kernel module with the 5.11 kernel. So, to work around this, I need to keep using the 5.10 kernel instead.

But I can't, because when I boot with the 5.10 kernel this is what shows up in /var/log/Xorg.0.log when gdm3 tries to start up the login screen (note: I have an NVIDIA graphics card, which is why (I believe) Wayland isn't being used here):

[ 857.957] (EE) modeset(G0): drmSetMaster failed: Device or resource busy
[ 857.957] (EE)
Fatal server error:
[ 857.957] (EE) AddScreen/ScreenInit failed for gpu driver 0 -1
[ 857.957] (EE)
[ 857.957] (EE)
Please consult the The X.Org Foundation support
  at http://wiki.x.org
 for help.
[ 857.957] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 857.957] (EE)
[ 858.144] (EE) Server terminated with error (1). Closing log file.

This is probably not what you will see in the Xorg.0.log (if any) attached automatically to this bug because I've completely wiped the evdi kernel module from my system since that was the only way I could get a display manager up so I could use ubuntu-bug to submit this bug.

Here's what I updated today:

2021-03-18 15:03:26 upgrade sysvinit-utils:amd64 2.96-5ubuntu1 2.96-6ubuntu1
2021-03-18 15:03:27 upgrade cron:amd64 3.0pl1-136ubuntu1 3.0pl1-136ubuntu2
2021-03-18 15:03:28 upgrade gpg-wks-client:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:28 upgrade dirmngr:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:29 upgrade gpg-wks-server:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:29 upgrade gnupg-utils:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:29 upgrade gpg-agent:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:30 upgrade gpg:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:30 upgrade gpgconf:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:30 upgrade gnupg-l10n:all 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:31 upgrade gnupg:all 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:31 upgrade gpgsm:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:31 upgrade gpgv:amd64 2.2.20-1ubuntu2 2.2.20-1ubuntu3
2021-03-18 15:03:32 upgrade libjs-sphinxdoc:all 3.5.1-2 3.5.2-1
2021-03-18 15:03:33 upgrade libnfsidmap2:amd64 0.25-5.1ubuntu2 0.25-6
2021-03-18 15:03:33 install linux-modules-5.11.0-11-generic:amd64 <none> 5.11.0-11.12
2021-03-18 15:03:35 install linux-image-5.11.0-11-generic:amd64 <none> 5.11.0-11.12
2021-03-18 15:03:36 install linux-modules-extra-5.11.0-11-generic:amd64 <none> 5.11.0-11.12
2021-03-18 15:03:40 upgrade linux-generic:amd64 5.10.0.14.16 5.11.0.11.12
2021-03-18 15:03:40 upgrade linux-image-generic:amd64 5.10.0.14.16 5.11.0.11.12
2021-03-18 15:03:41 install linux-headers-5.11.0-11:all <none> 5.11.0-11.12
2021-03-18 15:03:44 install linux-headers-5.11.0-11-generic:amd64 <none> 5.11.0-11.12
2021-03-18 15:03:47 upgrade linux-headers-generic:amd64 5.10.0.14.16 5.11.0.11.12
2021-03-18 15:03:47 upgrade linux-libc-dev:amd64 5.10.0-14.15 5.11.0-11.12
2021-03-18 15:03:48 upgrade slack-desktop:amd64 4.13.0 4.14.0
2021-03-18 15:03:52 upgrade xwayland:amd64 2:1.20.10-3ubuntu3 2:21.0.99.902-0ubuntu1
2021-03-18 15:56:42 upgrade at:amd64 3.1.23-1.1ubuntu2 3.1.23-1.1ubuntu3

At first glance I don't understand how any of these could be causing this behavior.

Potentially relevant: I had to recompile and reinstall the evdi kernel module while booted into 5.10 because when I install the 5.11 kernel dkms removed the module from 5.10 and then failed to rebuild it because the 5.11 build failed (or something I don't really understand why dkms does what it does *sigh*). I don't see how that should matter because the recompiled version of the module should have been identical, but *shrug*.

As noted above, when I remove the evdi kernel modules from /lib/modules and reboot with 5.10 the problem goes away, so this does appear to be an evdi issue.

In short: despite the fact that it's not clear how upgrading any of the modules listed above would cause evdi that used to work to suddenly stop working, that appears to be the case. Any advice would be appreciated because now I can't use the displays connected to my DisplayLink hub with either 5.10 or 5.11 kernels, despite the fact that they worked with the 5.10 kernel before today.

Please let me know if there's any other info you need here.

ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: xserver-xorg 1:7.7+22ubuntu1
ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11
Uname: Linux 5.10.0-14-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
.proc.driver.nvidia.gpus.0000.01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0000:01:00.0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.141 Mon Dec 28 16:21:32 UTC 2020
 GCC version: gcc version 10.2.1 20210220 (Ubuntu 10.2.1-20ubuntu1)
.tmp.unity_support_test.0:

ApportVersion: 2.20.11-0ubuntu60
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: unknown
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 18 16:32:16 2021
DistUpgraded: 2021-02-21 12:14:33,907 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
DistroCodename: hirsute
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: PNY GM204 [GeForce GTX 970] [196e:1131]
InstallationDate: Installed on 2019-01-02 (806 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
MachineType: Acer Predator G6-710
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.10.0-14-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
SourcePackage: xorg
UpgradeStatus: Upgraded to hirsute on 2021-02-21 (25 days ago)
dmi.bios.date: 05/18/2016
dmi.bios.release: 5.11
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: R01-A4
dmi.board.name: Predator G6-710
dmi.board.vendor: Acer
dmi.chassis.type: 3
dmi.chassis.vendor: Acer
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrR01-A4:bd05/18/2016:br5.11:svnAcer:pnPredatorG6-710:pvr:rvnAcer:rnPredatorG6-710:rvr:cvnAcer:ct3:cvr:
dmi.product.family: Acer Desktop
dmi.product.name: Predator G6-710
dmi.sys.vendor: Acer
version.compiz: compiz 1:0.9.14.1+20.10.20200813-0ubuntu4
version.libdrm2: libdrm2 2.4.104-1build1
version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.0-1
version.libgl1-mesa-glx: libgl1-mesa-glx 21.0.0-1
version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.10-3ubuntu3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-1

[Jonathan Kamens (jik)]

I debugged this further and discovered that one of the following updates caused evdi with kernel 5.10 to start failing as described above:

2021-03-18 21:55:45 upgrade libegl-mesa0:amd64 20.3.4-1 21.0.0-1
2021-03-18 21:55:45 upgrade libgbm1:amd64 20.3.4-1 21.0.0-1
2021-03-18 21:55:45 upgrade libgl1-mesa-dri:i386 20.3.4-1 21.0.0-1
2021-03-18 21:55:46 upgrade libgl1-mesa-dri:amd64 20.3.4-1 21.0.0-1
2021-03-18 21:55:47 upgrade libglx-mesa0:i386 20.3.4-1 21.0.0-1
2021-03-18 21:55:48 upgrade libglx-mesa0:amd64 20.3.4-1 21.0.0-1
2021-03-18 21:55:48 upgrade libglapi-mesa:amd64 20.3.4-1 21.0.0-1
2021-03-18 21:55:48 upgrade libglapi-mesa:i386 20.3.4-1 21.0.0-1

When I downgraded all of the listed debs to the old version indicated (20.3.4-1) and rebooted, evdi with kernel 5.10 started working again. So I guess this is a mesa bug?

[Daniel van Vugt (vanvugt)]

When drmSetMaster fails it generally means a display server (Xorg) is trying to start while some other display server is already busy with the graphics hardware (has not yet called drmDropMaster).

That "other" display server might be plymouthd if the login screen fails to start. To test that theory you can try changing the kernel parameter "splash" to "nosplash".

[Jonathan Kamens (jik)]

I performed the splash -> nosplash test described above; it made no difference.

[Daniel van Vugt (vanvugt)]

Yeah I wrote that before your Mesa findings :)

[Jonathan Kamens (jik)]

For those of you who landed here looking for how to use DisplayLink in Hirsute, I wrote up a workaround here: https://blog.kamens.us/2021/03/19/update-on-using-displaylink-with-ubuntu-21-04-hirsute-hippo/

[Łukasz Spintzyk (lspintzy)]

This https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1931547 is fixing that bug.