Delay on gdm load

crustovsky · 2025-04-09 21:19:14

I'm runing up to date Arch with Gnome 48 and 6.14.1 Kernel, when booting i can see up to 10s delay on reached graphical interface line, here https://0x0.st/8LzT.txt is output of

(sudo lspci -k; sudo journalctl -b) | curl -F 'file=@-' 0x0.st

In case it's relevant laptop has Ryzen 9 AI 365 with Radeon 880M and no other gpu's.

Note i had the same issue with 6.13 kernel and Gnome 47 as well.

seth · 2025-04-10 07:11:24

Apr 09 21:51:58 crustovskyarch kernel: Linux version 6.14.1-arch1-1 (linux@archlinux) (gcc (GCC) 14.2.1 20250207, GNU ld (GNU Binutils) 2.44) #1 SMP PREEMPT_DYNAMIC Mon, 07 Apr 2025 19:59:13 +0000
Apr 09 21:52:00 crustovskyarch systemd[1]: Reached target Graphical Interface.
Apr 09 21:52:05 crustovskyarch NetworkManager[800]: <info>  [1744231925.7547] manager: NetworkManager state is now CONNECTED_GLOBAL
Apr 09 21:52:06 crustovskyarch tailscaled[878]: wgengine: Reconfig: configuring DNS
Apr 09 21:52:08 crustovskyarch wpa_supplicant[1013]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-50 noise=9999 txrate=960700
Apr 09 21:52:10 crustovskyarch systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Apr 09 21:52:10 crustovskyarch systemd[1]: Configuration file /usr/lib/systemd/system/accounts-daemon.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Apr 09 21:52:10 crustovskyarch systemd[1]: Configuration file /usr/lib/systemd/system/accounts-daemon.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Apr 09 21:52:10 crustovskyarch systemd[1]: Reached target User and Group Name Lookups.
Apr 09 21:52:10 crustovskyarch systemd-logind[807]: New session 1 of user gdm.
Apr 09 21:52:19 crustovskyarch systemd-logind[807]: New session 3 of user michal.

systemd-analyze critical-chain
systemd-analyze plot > whatstakingsolong.svg

But w/ https://unix.stackexchange.com/question … nts-daemon the accounts-daemon.service hinges on nss-user-lookup.target which probably waits for tailscale.

Sidebar: there's absolutely no excuse for you to not have one of the best avatars ever.

crustovsky · 2025-04-10 10:13:57

Here is critical-chain output

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1.800s
└─power-profiles-daemon.service @1.761s +37ms
  └─multi-user.target @1.758s
    └─tailscaled.service @1.697s +59ms
      └─NetworkManager.service @1.594s +83ms
        └─basic.target @1.593s
          └─dbus-broker.service @1.556s +34ms
            └─dbus.socket @1.548s
              └─sysinit.target @1.543s
                └─systemd-update-utmp.service @1.517s +24ms
                  └─systemd-tmpfiles-setup.service @1.463s +52ms
                    └─systemd-journal-flush.service @1.404s +56ms
                      └─var-log.mount @1.392s +4ms
                        └─dev-nvme0n1p2.device @307ms +283ms

And SVG is here https://filebin.net/3zq0awhm8dfke2sl for some reason 0x0.st gave me 502 when i tried to push this SVG in there

seth wrote:

Sidebar: there's absolutely no excuse for you to not have one of the best avatars ever.
http://0x0.st/8L8p.jpg

That avatar is definitely worth considering!

seth · 2025-04-10 12:02:30

tailscale is in the critical chain here, but neither blame nor plot suggest only 1.8s are spent in userspace and don't match the journal you posted?
Was this boot considerably faster?

crustovsky · 2025-04-10 12:15:03

No, not really, what i see consistently is that from "Reached target Graphical Interface" to login window i see just under 10s pause, here are no other part of boot that visibly stall

seth · 2025-04-10 13:49:43

Diable syncthing and tailscaled and see whether this gets you a faster GDM start
(but nb. that wpa_supplicant still takes ~4s to get ready)

crustovsky · 2025-04-10 15:27:35

Disabling tailscale and syncthing didn't help at all, i still have ~10s pause between "Reached target Graphicsl Interface" and login screen

Updated boot logs

http://0x0.st/8LT2.txt

seth · 2025-04-10 15:35:57

Re-check blame but from the journal it's (now) mullvad.
Because

Apr 10 16:17:53 crustovskyarch systemd[1]: Started GNOME Display Manager.
Apr 10 16:17:57 crustovskyarch mullvad-daemon[875]: [mullvad_api::availability][DEBUG] Resuming background API requests
Apr 10 16:17:57 crustovskyarch mullvad-daemon[875]: [mullvad_daemon::relay_list][DEBUG] Relay list is up-to-date
Apr 10 16:17:58 crustovskyarch systemd[1]: systemd-rfkill.service: Deactivated successfully.
Apr 10 16:18:00 crustovskyarch wpa_supplicant[921]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-35 noise=9999 txrate=25800
Apr 10 16:18:03 crustovskyarch wpa_supplicant[921]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-34 noise=9999 txrate=25800
Apr 10 16:18:03 crustovskyarch systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Apr 10 16:18:03 crustovskyarch accounts-daemon[948]: started daemon version 23.13.0
Apr 10 16:18:03 crustovskyarch systemd[1]: Started Accounts Service.
Apr 10 16:18:03 crustovskyarch systemd-logind[812]: New session 1 of user gdm.

Also, just for goo measure, fix

Apr 10 16:18:03 crustovskyarch systemd[1]: Configuration file /usr/lib/systemd/system/accounts-daemon.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Apr 10 16:18:03 crustovskyarch systemd[1]: Configuration file /usr/lib/systemd/system/accounts-daemon.service is marked executable. Please remove executable permission bits. Proceeding anyway.

crustovsky · 2025-04-10 16:32:06

I disabled Mullvad and fixed the permissions

In between

Apr 10 17:25:53 crustovskyarch systemd[1]: Reached target Graphical Interface.

and +10s it looks like it's just Network manager

Updated critical chain

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1.783s
└─power-profiles-daemon.service @1.760s +21ms
  └─multi-user.target @1.754s
    └─systemd-user-sessions.service @1.746s +7ms
      └─network.target @1.735s
        └─NetworkManager.service @1.621s +112ms
          └─basic.target @1.620s
            └─dbus-broker.service @1.582s +35ms
              └─dbus.socket @1.576s
                └─sysinit.target @1.573s
                  └─systemd-update-utmp.service @1.539s +31ms
                    └─systemd-tmpfiles-setup.service @1.491s +46ms
                      └─systemd-journal-flush.service @1.407s +81ms
                        └─var-log.mount @1.393s +7ms
                          └─dev-nvme0n1p2.device @313ms +274ms

Updated boot logs again

http://0x0.st/8LwI.txt

crustovsky · 2025-04-10 16:40:34

I even disabled NetworkManager and wait still feels unchanged

seth · 2025-04-10 19:26:03

Do you have a journal and critical-chain for /that/ run?

crustovsky · 2025-04-11 09:52:07

seth wrote:

Do you have a journal and critical-chain for /that/ run?

I did it again so here is a journal https://0x0.st/8pKJ.txt and critical chain

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1.841s
└─power-profiles-daemon.service @1.820s +20ms
  └─multi-user.target @1.817s
    └─systemd-logind.service @1.791s +24ms
      └─basic.target @1.786s
        └─dbus-broker.service @1.772s +12ms
          └─dbus.socket @1.765s
            └─sysinit.target @1.762s
              └─systemd-update-done.service @1.733s +27ms
                └─ldconfig.service @1.555s +175ms
                  └─systemd-tmpfiles-setup.service @1.496s +56ms
                    └─systemd-journal-flush.service @1.424s +70ms
                      └─var-log.mount @1.412s +5ms
                        └─dev-nvme0n1p2.device @325ms +282ms

crustovsky · 2025-04-11 11:59:18

I also enabled debug logging for GDM in

/etc/gdm/custom.conf

and here are gdm logs for last boot https://0x0.st/8pZX.txt

These are suspicious i think

Apr 11 12:50:30 crustovskyarch gdm[911]: Gdm: GdmLocalDisplayFactory: New displays on seat0 will use wayland
Apr 11 12:50:30 crustovskyarch gdm[911]: Gdm: GdmLocalDisplayFactory: seat0 doesn't yet support graphics.  Waiting 10 seconds to try again.
Apr 11 12:50:30 crustovskyarch gdm[911]: Gdm: GdmLocalDisplayFactory: received VT change event
Apr 11 12:50:30 crustovskyarch gdm[911]: Gdm: GdmLocalDisplayFactory: VT is 1 at startup
Apr 11 12:50:41 crustovskyarch gdm[911]: Gdm: GdmLocalDisplayFactory: display for seat seat0 requested

Not sure if related but there doesn't seem to be "card0" on my system

❯ ls /sys/class/drm
card1  card1-DP-1  card1-DP-2  card1-DP-3  card1-DP-4  card1-DP-5  card1-DP-6  card1-eDP-1  card1-HDMI-A-1  card1-Writeback-1  renderD128  version

seth · 2025-04-11 14:18:19

Seems a GDM false-positive?

Apr 11 09:40:22 crustovskyarch kernel: amdgpu 0000:62:00.0: amdgpu: Runtime PM not available
Apr 11 09:40:22 crustovskyarch kernel: amdgpu 0000:62:00.0: [drm] Registered 4 planes with drm panic
Apr 11 09:40:22 crustovskyarch kernel: [drm] Initialized amdgpu 3.61.0 for 0000:62:00.0 on minor 1
Apr 11 09:40:22 crustovskyarch kernel: [drm] pre_validate_dsc:1601 MST_DSC dsc precompute is not needed
Apr 11 09:40:22 crustovskyarch kernel: amdgpu 0000:62:00.0: [drm] fb0: amdgpudrmfb frame buffer device
Apr 11 09:40:22 crustovskyarch systemd[1]: Starting Load Kernel Module drm...
Apr 11 09:40:22 crustovskyarch systemd[1]: modprobe@drm.service: Deactivated successfully.
Apr 11 09:40:22 crustovskyarch systemd[1]: Finished Load Kernel Module drm.
Apr 11 09:40:23 crustovskyarch kernel: [drm] Initialized amdxdna_accel_driver 0.0.0 for 0000:63:00.1 on minor 0
Apr 11 09:40:23 crustovskyarch systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1...
Apr 11 09:40:23 crustovskyarch systemd[1]: Finished Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1.
Apr 11 09:40:23 crustovskyarch kernel: snd_hda_intel 0000:62:00.1: bound 0000:62:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
Apr 11 09:40:24 crustovskyarch systemd[1]: Starting GNOME Display Manager...

The entire amdgpu/drm complex is done before GDM starts (and you've amdgpu in the initramfs)
card0 is taken bythe simpledrm device, add "nvidia_drm.modeset=1" to the kernel parameters (it there serves as a hack to completely block the simpledrm device, it doesn't matter that there's no nvidia GPU)

Can you launch GDM on X11 w/o delay?
https://wiki.archlinux.org/title/GDM#Use_Xorg_backend

crustovsky · 2025-04-11 14:38:26

Adding "nvidia_drm.modeset=1" and forcing GDM on X11 didn't have effect, delay is still there including "Gdm: GdmLocalDisplayFactory: seat0 doesn't yet support graphics. Waiting 10 seconds to try again." message

seth · 2025-04-11 15:19:20

To check whether it's a misconception by GDM/gnome-shell or the GPU is indeed that slow, try eg. lightdm?

crustovsky · 2025-04-11 15:45:34

I went with SDDM and i've got login window instantly without any delays

seth · 2025-04-12 07:30:46

So……… is GDM early or stupid?

systemctl edit gdm.service

[Service]
ExecStartPre=/usr/bin/sleep 2

This is supposed to introduce an artificial 2s delay - let's see whether it avoids GDMs 10s timeout.

crustovsky · 2025-04-12 18:38:53

So looks like GDM is both, slow and stupid 2, 5, 10s do not have any effect, it's still doing the 10s wait

Gdm: GdmLocalDisplayFactory: seat0 doesn't yet support graphics.  Waiting 10 seconds to try again.

seth · 2025-04-12 20:50:20

https://gitlab.gnome.org/GNOME/gdm/-/issues/974

Does a udev rule setting

ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"

convice it to prettyplease use that card?
https://gitlab.gnome.org/GNOME/mutter/- … uests/1562

crustovsky · 2025-04-12 22:43:34

Nope no effect, also it's card0 now, not sure how "Unknown device "/dev/dri/card1": No such device"

❯ udevadm info --query=all --name=/dev/dri/card0 | grep -i tag
E: ID_PATH_TAG=pci-0000_62_00_0
E: TAGS=:mutter-device-preferred-primary:uaccess:seat:master-of-seat:
E: CURRENT_TAGS=:mutter-device-preferred-primary:uaccess:seat:master-of-seat:

seth · 2025-04-13 06:52:49

Sorry, forgot that we did https://bbs.archlinux.org/viewtopic.php … 0#p2236590 (hence card0, that's ok)

Your GPU falls into the linked bug, so if you cannot convince mutter this way (and don't want ot patch the kernel for this with what's likely wrong and not upstreamable) you'll have to wait for a GDM/mutter patch or upstream suggestion to work around this

tekstryder · 2025-04-13 12:47:50

crustovsky wrote:

Nope no effect, also it's card0 now, not sure how "Unknown device "/dev/dri/card1": No such device"

Perhaps try the more verbose specific rule creation from the last couple comments in the bug report:

SUBSYSTEM=="drm", ENV{DEVTYPE}=="drm_minor", ENV{DEVNAME}=="/dev/dri/card[0-9]", SUBSYSTEMS=="pci", ATTRS{vendor}=="0x1002", ATTRS{device}=="0x73ff", TAG+="mutter-device-preferred-primary"

Kamil Szczęk wrote:

You can find your vendor and device IDs using lspci -nn.

Italo Baeza Cabrera wrote:

be sure to add the leading 0x

EDIT: This should allow the rule to work regardless of cardX assignment.

Last edited by tekstryder (2025-04-13 12:52:15)

crustovsky · 2025-04-13 21:31:58

I made sure that leading 0x is in place and that IDs are correct, and they are, still having that 10s stall

Rule looks to be in place

❯ udevadm info /dev/dri/card0
P: /devices/pci0000:00/0000:00:08.1/0000:62:00.0/drm/card0
M: card0
R: 0
J: c226:0
U: drm
T: drm_minor
D: c 226:0
N: dri/card0
L: 0
S: dri/by-path/pci-0000:62:00.0-card
E: DEVPATH=/devices/pci0000:00/0000:00:08.1/0000:62:00.0/drm/card0
E: DEVNAME=/dev/dri/card0
E: DEVTYPE=drm_minor
E: MAJOR=226
E: MINOR=0
E: SUBSYSTEM=drm
E: USEC_INITIALIZED=5398872
E: ID_PATH=pci-0000:62:00.0
E: ID_PATH_TAG=pci-0000_62_00_0
E: ID_FOR_SEAT=drm-pci-0000_62_00_0
E: DEVLINKS=/dev/dri/by-path/pci-0000:62:00.0-card
E: TAGS=:uaccess:mutter-device-preferred-primary:master-of-seat:seat:
E: CURRENT_TAGS=:uaccess:mutter-device-preferred-primary:master-of-seat:seat:

Perpahs issue is with some other device confusing gdm/mutter?

❯ lspci -nn
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Root Complex [1022:1507]
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo IOMMU [1022:1508]
00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509]
00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo PCIe USB4 Bridge [1022:150a]
00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509]
00:02.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo GPP Bridge [1022:150b]
00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo GPP Bridge [1022:150b]
00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509]
00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Dummy Host Bridge [1022:1509]
00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Internal GPP Bridge to Bus [C:A] [1022:150c]
00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Internal GPP Bridge to Bus [C:A] [1022:150c]
00:08.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo Internal GPP Bridge to Bus [C:A] [1022:150c]
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 71)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51)
00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 0 [1022:16f8]
00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 1 [1022:16f9]
00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 2 [1022:16fa]
00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 3 [1022:16fb]
00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 4 [1022:16fc]
00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 5 [1022:16fd]
00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 6 [1022:16fe]
00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Strix Data Fabric; Function 7 [1022:16ff]
60:00.0 Non-Volatile memory controller [0108]: Micron Technology Inc 2550 NVMe SSD (DRAM-less) [1344:5416] (rev 01)
61:00.0 Network controller [0280]: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:0616]
62:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Strix [Radeon 880M / 890M] [1002:150e] (rev c4)
62:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller [1002:1640]
62:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Strix/Krackan/Strix Halo CCP/ASP [1022:17e0]
62:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151e]
62:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 70)
62:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller [1022:15e3]
63:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Strix/Strix Halo PCIe Dummy Function [1022:150d]
63:00.1 Signal processing controller [1180]: Advanced Micro Devices, Inc. [AMD] Strix/Krackan/Strix Halo Neural Processing Unit [1022:17f0] (rev 10)
64:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151f]
64:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151a]
64:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151b]
64:00.5 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Device [1022:151c]

seth · 2025-04-13 21:44:58

The problem is that the Strix Display Controller isn't tagged as VGA device - as mentioned, you fit the upstream bug.
Setting the default mutter device was merely a wild guess what *might* convince mutter to skip those checks, but apparently simply doesn't.

Arch Linux

#1 2025-04-09 21:19:14

Delay on gdm load

#2 2025-04-10 07:11:24

Re: Delay on gdm load

#3 2025-04-10 10:13:57

Re: Delay on gdm load

#4 2025-04-10 12:02:30

Re: Delay on gdm load

#5 2025-04-10 12:15:03

Re: Delay on gdm load

#6 2025-04-10 13:49:43

Re: Delay on gdm load

#7 2025-04-10 15:27:35

Re: Delay on gdm load

#8 2025-04-10 15:35:57

Re: Delay on gdm load

#9 2025-04-10 16:32:06

Re: Delay on gdm load

#10 2025-04-10 16:40:34

Re: Delay on gdm load

#11 2025-04-10 19:26:03

Re: Delay on gdm load

#12 2025-04-11 09:52:07

Re: Delay on gdm load

#13 2025-04-11 11:59:18

Re: Delay on gdm load

#14 2025-04-11 14:18:19

Re: Delay on gdm load

#15 2025-04-11 14:38:26

Re: Delay on gdm load

#16 2025-04-11 15:19:20

Re: Delay on gdm load

#17 2025-04-11 15:45:34

Re: Delay on gdm load

#18 2025-04-12 07:30:46

Re: Delay on gdm load

#19 2025-04-12 18:38:53

Re: Delay on gdm load

#20 2025-04-12 20:50:20

Re: Delay on gdm load

#21 2025-04-12 22:43:34

Re: Delay on gdm load

#22 2025-04-13 06:52:49

Re: Delay on gdm load

#23 2025-04-13 12:47:50

Re: Delay on gdm load

#24 2025-04-13 21:31:58

Re: Delay on gdm load

#25 2025-04-13 21:44:58

Re: Delay on gdm load

Board footer