FS#66758 - [xorg-server] early start of xorg-server crash when not using early KMS

Attached to Project: Arch Linux
Opened by Max Gautier (VannTen) - Saturday, 23 May 2020, 18:31 GMT
Last edited by Andreas Radke (AndyRTR) - Monday, 21 June 2021, 19:10 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Using the aur packages https://aur.archlinux.org/packages/xlogin-git/ led me to observe a weird behaviour of X
When using it normally, the expected result is to boot into the DE specified in .xinitrc
(Relevant wiki page : https://wiki.archlinux.org/index.php/Systemd/User#Automatic_login_into_Xorg_without_display_manager)

However, this does not work. The X server aborts, and I'm dumped on vt1, where i can login, then start the xlogin@user service, which then works.

The solution suggested on the last post here (https://bbs.archlinux.org/viewtopic.php?id=207631), that is, using early KMS start, works. (https://wiki.archlinux.org/index.php/kernel_mode_setting#Early_KMS_start)

Attached :
Xorg.0.log (with early KMS)
Xorg.0.log.old (without early KMS)


Steps to reproduce:

- install xlogin-git from AUR
- enable xlogin@username
- reboot (X crash when booting)
- log into the vt
- run as root "systemctl start xlogin@username" (X start and the DE works)
- modify the mkinitcpio.conf addings "nouveau" in the MODULES section
- regenerate the initramfs
- reboot (Works like a charm).
   Xorg.0.log (32.2 KiB)
   Xorg.0.log.old (35.5 KiB)
   mkinitcpio.conf (2.5 KiB)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Monday, 21 June 2021, 19:10 GMT
Reason for closing:  No response
Additional comments about closing:  and use of AUR packages
Comment by Emil (xexaxo) - Thursday, 03 December 2020, 14:45 GMT
Might be worth checking if the problem persists with latest updates and it so - reporting upstream [0]:

From a quick look - in the "late" case, as the NV device/node comes up, the modesetting driver gets picked instead of nouveau (1). Ultimately ending in a crash during the glamoregl/acceleration init path (2). While in the early case - nouveau driver is used alongside EXA acceleration

[0] https://gitlab.freedesktop.org/xorg/xserver/-/issues
(1) (2) Two separate bugs I'd imagine.

Loading...