You are not logged in.

#1 2019-11-23 08:48:57

revivaloflostart
Member
Registered: 2018-08-09
Posts: 11

modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

Getting errors when I "startx". Started having this problem recently after a new update on an Arch system that was just installed a few days ago.


[   653.485\] (EE) modeset(0): drmSetMaster failed: Permission denied \[   653.485\] (EE) Fatal server error:
[   653.486\] (EE) AddScreen/ScreenInit failed for driver 0


When I installed Arch, I've only installed these for X (I have a Thinkpad x230 with Intel HD 4000 gpu):
xorg-server, xorg-xinit, mesa

Arch Wiki mentioned: xf86-video-intel (often not recommended) Note: Some (Debian & Ubuntu, Fedora, KDE) recommend not installing the xf86-video-intel driver, and instead falling back on the modesetting driver for Gen4 and newer GPUs (GMA 3000 from 2006 and newer). See \[1\], \[2\], Xorg#Installation, and modesetting(4). However, the modesetting driver can cause problems such as Chromium Issue 370022.

I have always installed Arch this way and never had to use xf86-video-intel. But how come I'm getting these errors now?

Someone from the archlinux irc told me to add my gpu driver to the initramfs by adding "i915" to the MODULES array in /etc/mkinitcpio.conf and rebuilding the images with "mkinitcpio -P" which solved the problem, but why is this necessary? I've never had to manually do this in the past.

In addition, this is what the wiki mentioned: Today, all necessary modules loading is handled automatically by udev, so if you do not need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any configuration file. Xorg searches for installed drivers automatically: If it cannot find the specific driver installed for the hardware (listed below), it first searches for fbdev (xf86-video-fbdev). If that is not found, it searches for vesa (xf86-video-vesa), the generic driver, which handles a large number of chipsets but does not include any 2D or 3D acceleration. If vesa is not found, Xorg will fall back to kernel mode setting, which includes GLAMOR acceleration (see modesetting(4)).

Isn't it  better to just let Xorg fall back to modesetting these days? and if so, why do i need to add "i915" to MODULES array in mkinitcpio.conf eventhough I don't have xf86-video-intel installed? and most importantly, why am i getting these errors and is adding "i915" to /etc/mkinitcpio.conf 's MODULES array and rebuilding the images with "mkinitcpio -p" the best fix?

Last edited by revivaloflostart (2019-11-23 08:52:12)

Offline

#2 2019-11-23 09:20:00

seth
Member
Registered: 2012-09-03
Posts: 49,951

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

Kernel and X11 driver are not strictly related, resp. the modesetting driver is a generic KMS driver for the display server, but you still need the kernel module (i915) to actually abstract KMS on the HW.

The actual reason for the early KMS "requirement" is afaik still unknown/bug not solved/notabug/works on lennarts system but it happens because: systemd (since v243 X11 starts before logind has done its stuff) - might be entropy related, but it's for pretty much sure a race condition. There're several topics itr. on the forum.


On a sidenote:
Please structure future posts to start w/ the question at hand instead of burying in a wall of weirdly formatted text. I was about to link you the "enable KMS" posts…

Offline

#3 2019-11-23 10:08:50

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

@seth 243 added [1] and [2] but [2] does not work possibly because the device restriction has already been generated or is in use before ExecStartPre

Upstream bug report https://github.com/systemd/systemd/issues/13943

[1] https://github.com/systemd/systemd/comm … acab0bdec5
[2] https://github.com/systemd/systemd/comm … fa2a15d3b0

Offline

#4 2019-11-23 12:20:26

latalante1
Member
Registered: 2018-08-30
Posts: 110

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

Loading hardware drivers, necessary for the proper operation of the system at the earliest possible stage of booting is not to bypass but the most sensible solution (maybe the only correct one).
Counting that the systemd-logind service will be properly initialized with the simultaneous loading of the DRM module is counting on a miracle.
Initializing i915 can take over a second.
https://www.linuxplumbersconf.org/event … he_way.pdf

A lot of them are looking for the fastest way to start the system by compiling all drivers permanently into the kernel. Others are looking for more sophisticated solutions.

Last edited by latalante1 (2019-11-23 12:27:33)

Offline

#5 2019-11-23 14:43:02

cirrus
Member
From: Glasgow Scotland
Registered: 2012-08-24
Posts: 340
Website

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

revivaloflostart wrote:

I have a Thinkpad x230 with Intel HD 4000 gpu

I use a x220 xf86-video-intel works fine for me with early kms, the modesetting driver causes random crashes due to https://www.phoronix.com/scan.php?page= … ble-Atomic

Offline

#6 2019-12-09 10:05:39

bachtiar
Member
Registered: 2005-02-08
Posts: 64

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

I am experienced the same issue when starting xorg as non-root. I am running as a qemu/KVM guest. In my xorg.log, I get:

modeset(0): drmSetMaster failed: Permission denied

I found out that the problem only appears when xorg is installed from arch-chroot during initial system installation (booted from archiso).
The problem does not appear if I finish the installation without xorg and install xorg later when the system is already running.
Notably, root user can always run X (regardless of how it was installed).

Perhaps this has something to do with post-transaction hooks being skipped in arch-chroot? E.g.

:: Running post-transaction hooks...
(1/6) Reloading system manager configuration...
Running in chroot, ignoring request: daemon-reload
(2/6) Creating temporary files...
(3/6) Reloading device manager configuration...
Running in chroot, ignoring request.
(4/6) Arming ConditionNeedsUpdate...
(5/6) Updating fontconfig cache...
(6/6) Updating X fontdir indices...

Last edited by bachtiar (2019-12-09 10:08:52)

Offline

#7 2019-12-09 11:28:55

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,410

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

This is a race condition, whether you install xorg initially or afterwards should not matter for the inherent cause of the issue, it can and cannot happen on each boot, depending on how fast certain things finished starting up.

Last edited by V1del (2019-12-09 11:33:28)

Offline

#8 2020-02-01 11:10:25

mikpom
Member
Registered: 2020-01-06
Posts: 11

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

revivaloflostart wrote:

Someone from the archlinux irc told me to add my gpu driver to the initramfs by adding "i915" to the MODULES array in /etc/mkinitcpio.conf and rebuilding the images with "mkinitcpio -P" which solved the problem, but why is this necessary? I've never had to manually do this in the past.

Would like to assert that this solved my very similar issue when running Arch as a guest OS with QEMU.

Offline

#9 2020-02-06 00:38:18

mixer
Member
Registered: 2013-08-16
Posts: 47

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

I was seeing this race condition where startx failed 30% of the time.  Adding my video card driver to /etc/mkinitcpio.conf fixed it.

$ lspci -k | grep -A 2 -E "(VGA|3D)" | grep driver
        Kernel driver in use: nouveau

Added "nouveau" to mkinitcpio.conf and remade ramdisk:

$ grep ^MODULES /etc/mkinitcpio.conf
MODULES=(nouveau)
$ sudo mkinitcpio -p linux
$ sudo systemctl reboot

Offline

#10 2020-02-08 16:21:46

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: modset(0): drmSetMaster failed: permission denied. AddScreen/Init fail

Fixed with systemd 244.2-2

Offline

Board footer

Powered by FluxBB