Gnome freezes upon login

ajje · 2024-02-18 00:00:52

I recently installed Arch Linux and everything is running fine, but after booting up and logging in with GDM the whole screen sometimes freezes and I can't do anything (not change TTY, do alt-F2 etc).

Pushing the power button on my computer, however, reveals the booting up terminal, showing the system shutting off line by line.

This happens very frequently, like two thirds of all boots. And as far as I can tell it's only after a boot – logging out and logging in after a successful login will not trigger the freeze.

Another, perhaps related issue, is that before even entering the GDM, the screen sometimes loses the connection with the computer ("No Signal") and I have to manually reboot.

You can find the `sudo journalctl -b -1` results of my latest Gnome login freeze here: https://0x0.st/HnO5.txt

Windmill · 2024-02-19 04:19:39

I have the same issue. Need to hard reboot when it freezes, can't even change TTY.

I'm using amdgpu and I can see that you do too. Maybe it's an amdgpu issue? It started happening a week ago for me.

ajje · 2024-02-19 06:41:09

That's interesting, I'm afraid I haven't had Arch Linux installed long enough on this machine to tell you when it started, but it sure has intensified the couple of days and I try to not reboot as to avoid this issue.

Do you also sometimes get the "No Signal" just before the GDM or just the freeze after supplying correct login credentials?

seth · 2024-02-19 09:16:09

Try to add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters and for a complete curveball,

Feb 18 00:09:27 archlinux kernel: usb 1-9: Found UVC 1.00 device USB 2.0 Camera (0c45:6367)
Feb 18 00:09:28 archlinux mtp-probe[612]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-9"
Feb 18 00:09:31 archlinux kernel: usb 1-9: 3:1: cannot get freq at ep 0x84
Feb 18 00:09:31 archlinux kernel: usb 1-9: 3:1: cannot get freq at ep 0x84

remove that camera.
Can you replicate the behavior w/ the LTS kernel?

@Windmill, please share a journal for pattern comparism.

ajje · 2024-02-19 10:34:36

I removed the camera and rebooted a few times without problems, and then I plugged it in again and have tried to replicate the freeze by rebooting a few times but it logs in just fine now.

I still get those "kernel: usb 1-9: 3:1: cannot get freq at ep 0x84" messages in the journal, however.

If it starts freezing again I'll test adding the kernel parameter as per your suggestion (and changing the kernel to the LTS one).

mwillems · 2024-02-19 17:07:35

So I also have been seeing this issue intermittently for some time and am also on AMDGPU. One thing that I can confirm is that while the system won't respond to Ctrl-Alt-Number, the system still does respond to SysRq keys once it's hung. When I start REISUB after SysRq R and E the system dumps me back to the GDM screen where I can then login or reboot without a hard reboot. Another nice thing about the SysRq is that using them shows up in the journal so you easily see what journal entries immediately precede the hang.

For comparison, I don't have a camera attached at all.

For me the journal entries immediately preceding the hang seem to be related to gnome screensaver failing. I just had a freeze on login this morning and this journal block appears to be where things started going wrong just before I had to SysRq:

Feb 19 11:48:43 [hostname] gnome-session[1799]: gnome-session-binary[1799]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Feb 19 11:48:43 [hostname] gnome-session-binary[1799]: WARNING: Could not retrieve current screensaver active state: Timeout was reached

I can confirm that these entries do not appear when I can successfully log in. Your logs also include the same screensaver errors shortly before your hard reboot. So I strongly suspect the issue relates to how gnome-session-binary is interacting with gnome-screensaver, but I'm not sure how to get farther than that.

Here's a full journal of a failed login for comparison: https://0x0.st/Hn0q.txt. The freeze happens shortly before 11:49:02 (where the first SysRq press occurs)

Last edited by mwillems (2024-02-19 17:20:22)

ajje · 2024-02-19 17:20:00

mwillems wrote:

I can confirm that these entries do not appear when I can successfully log in.

This is true for me, too. I don't get these entries when logging in successfully.

micronetic · 2024-02-19 17:25:01

seth wrote:

Try to add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters and for a complete curveball, remove that camera.

Okay wow, I had the same problems but I am on an nvidia card, I am usually using the nvidia-open package, tried the nvidia package but it happened there too and only with Wayland.

Now I just removed the webcam and I can enter the Wayland session again after I enter my GDM login, lol, this is funy.

THANK YOU!

Last edited by micronetic (2024-02-19 17:26:01)

seth · 2024-02-19 17:33:39

ajje wrote:

mwillems wrote:
I can confirm that these entries do not appear when I can successfully log in.
This is true for me, too. I don't get these entries when logging in successfully.

Feb 19 11:48:42 hostname systemd[1637]: Starting GNOME FreeDesktop screensaver service...
Feb 19 11:48:42 hostname systemd[1637]: Started GNOME FreeDesktop screensaver service.
Feb 19 11:48:42 hostname systemd[1637]: Created slice Slice /app/dbus-:1.2-org.gnome.ScreenSaver.
Feb 19 11:48:42 hostname systemd[1637]: Reached target GNOME FreeDesktop screensaver target.
Feb 19 11:48:42 hostname systemd[1637]: Started dbus-:1.2-org.gnome.ScreenSaver@0.service.
Feb 19 11:48:43 hostname gnome-session[1799]: gnome-session-binary[1799]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Feb 19 11:48:43 hostname gnome-session-binary[1799]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Feb 19 11:49:04 hostname unknown[2056]: Error releasing name org.freedesktop.ScreenSaver: The connection is closed
Feb 19 11:49:04 hostname systemd[1637]: Stopped dbus-:1.2-org.gnome.ScreenSaver@0.service.

This heavily smells like a dbus-broker thing - can you replicate the issue at all when switching (back) to dbus-dameon-units?

seth · 2024-02-19 17:36:26

micronetic wrote:

Okay wow, I had the same problems but I am on an nvidia card, I am usually using the nvidia-open package, tried the nvidia package but it happened there too and only with Wayland.
Now I just removed the webcam and I can enter the Wayland session again after I enter my GDM login, lol, this is funy.

Might be just a fluke.
But if you get "cannot get freq at ep" errors as well, try to plug the cam into a different port, preferably an USB3 one (don't have to be "C", usb3 provides nearly twice the power)

mwillems · 2024-02-19 17:51:07

seth wrote:

This heavily smells like a dbus-broker thing - can you replicate the issue at all when switching (back) to dbus-daemon-units?

So I tried switching back to dbus-daemon-units and got the same hang on the next boot, but without the same journal errors. So you were correct that dbus-broker may have been causing the specific errors but with dbus-daemon-units I still got the hang without those specific errors (although there are a bunch of other errors upstream)

Here's a log of a failed boot with dbus-daemon-units:

https://0x0.st/Hn0Q.txt

Given that the errors only appear on a failed boot with dbus-broker-units, I suspect there's still a hint there though. It may just be that dbus-daemon-units is less verbose about what's failing (or is failing in a different way)?

Last edited by mwillems (2024-02-19 17:59:36)

seth · 2024-02-19 21:52:12

Feb 19 12:42:04 hostname systemd-logind[1044]: New session 3 of user username.
…
Feb 19 12:42:06 hostname udisksd[2185]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Feb 19 12:42:09 hostname systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Feb 19 12:42:18 hostname kernel: sysrq: Keyboard mode set to system default

You log in, then there's a lot of action for 2s then 3s later the NM dispatcher finishes … then nothing happens and 9s later you fire the sysrq.
There're no amdgpu or drm errors, yet clearly the framebuffer is locked. Somehow.

Try to add "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters to get rid of the simpledrm device.

mwillems · 2024-02-20 00:18:16

So I just tried adding that kernel parameter and rebooted a few times and got the hang again. Just for context, the issue had been consistently nondeterministic (it happens every three or four boots sometimes more sometimes less). I see the following in dmesg which I think confirms that the parameter is correctly applied:

[    0.044500] blacklisting initcall simpledrm_platform_driver_init
[    2.774909] initcall simpledrm_platform_driver_init blacklisted

But I got the login hang again, even with the driver blacklisted. The journal doesn't look meaningfully different: there's a lot of activity after login for a few seconds, network manager finishes and there's a hang. I reverted to dbus-broker after finding dbus-daemon did not fix the problem, and so I now also see the screensaver timeout errors and they appear just before network manager finishes also right before the SysRq keys.

So my most recent hang journal (with the simple drm blacklisted) in relevant part looks like:

Feb 19 19:00:11 Neptunian systemd-logind[1014]: New session 3 of user username.
...
Feb 19 19:00:13 hostname systemd[1]: Started Disk Manager.
Feb 19 19:00:13 hostname udisksd[2130]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Feb 19 19:00:13 hostname gnome-session[1774]: gnome-session-binary[1774]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Feb 19 19:00:13 hostname gnome-session-binary[1774]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Feb 19 19:00:16 hostname systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Feb 19 19:00:24 hostname kernel: sysrq: Keyboard mode set to system default

For context, in the past I tried leaving the hung situation at the grey screen for a while to see if anything would eventually happen, and it sat for fifteen minutes with no change, but still responded to SysRq keys afterwards.

Last edited by mwillems (2024-02-20 00:19:48)

mwohah · 2024-03-02 12:52:56

Am experiencing the same issue, along with the screensaver failure logs, on a system with an Intel iGPU and NVIDIA dGPU, so it's definitely not AMD-specific. Also started happening for me around the time of the dbus migration and am using dbus-broker myself.

Just wanted to mention these two similar topics that may or may not be of some use:

The systemd issue almost exactly seems to describe the symptoms: everything 'works' just fine, but the display just doesn't update. Not sure if it is the same cause though, since it's specific to 2.56 Git (Arch is on 2.55.4), and the log output mentioned doesn't appear here.

seth · 2024-03-02 17:09:46

screensaver is likely an indicator, not the cause.
We seem to have ruled out dbus-broker, https://bbs.archlinux.org/viewtopic.php … 0#p2151810 and the simpledrm device.
The kernel is most certainly alive (sysrq works) but the framebuffer is locked - though there're no resp. errors in the journal.
If you think you're facing the same issue, please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

There's also https://bbs.archlinux.org/viewtopic.php?id=292649 (amdgpu, again, slightly different symptoms)

mwohah · 2024-03-02 18:26:51

Here are my logs from a boot that experienced the issue, hopefully we'll be able to deduce something more from multiple systems.

Similar to the OP, the log 'Power key pressed short.' is where I had to press the power button to shut down.

EDIT: Not sure if relevant, but I'm using the scale-monitor-buffers experimental option in GNOME shell and but do not currently have a high DPI screen attached needing this option. It has always worked fine for me, but mentioning it for completeness. I'm also similarly using mutter-dynamic-buffering, previously without issue. Perhaps the OP is coincidentally using any of these, too?

EDIT2: FIxed the link to my logs, accidentally pasted the OP's link.

Last edited by mwohah (2024-03-02 19:25:00)

tb_83 · 2024-03-02 19:03:28

Same here, since today during login via GDM, mouse stuck, no access to TTY, only hard reset works.
It's a Dell XPS with hybrid graphics but runs only on intel graphics...

Link to bootlog is here.

Last edited by tb_83 (2024-03-02 19:04:29)

seth · 2024-03-02 21:29:19

The two of you a re on hybrid systems, nvidia open resp. nouveau.
nouveau becomes card0 and crashes, but both selecte the intel chip as primary card.
(Also there're no output on tb_83's nouveau card)

If we blame the intel chip, there's been a recent post where the PSR was causing massive lags and along fbc it's generally kinda prone to cause this.
Let's just throw "i915.enable_psr=0 i915.enable_fbc=0" at the problem, https://wiki.archlinux.org/title/Kernel_parameters

tb_83 · 2024-03-03 07:04:48

I would like to say that it's working. But the system was VERY slow and neither the reboot button nor a dodo reboot working. So I did a hard reset and after login, the mouse stucks after I reached the desktop. Next hard reset I can't access the desktop anymore. I checked the systems boot parameters and they are still there... I also tried with laptop on dock and off dock.

Here ist a new log from last stuck boot:

log

Last edited by tb_83 (2024-03-03 07:12:46)

seth · 2024-03-03 13:10:29

Mär 03 08:06:20 archlinux-c10 gnome-shell[2020]: Failed to open gpu '/dev/dri/card1': Zeitüberschreitung wurde erreicht
Mär 03 08:06:45 archlinux-c10 gnome-shell[2020]: Failed to open gpu '/dev/dri/card2': Zeitüberschreitung wurde erreicht

And nouveau is still crashing for you.
Add "module_blacklist=nouveau initcall_blacklist=simpledrm_platform_driver_init" next to the i915 parameters, this will block nouveau and the simpledrm device and make free way for i915

ynuwyytqaw · 2024-03-14 20:48:46

This is a me-too. On AMD 5700G, for what it is worth. My hope is on systemd version 256.

Captain Athelas · 2024-03-18 18:50:06

I have the same issue. I can see the following logs when the issue appears, but not when the issue has not been encountered:

mrt 18 19:28:34 <computer_name> gnome-session[1212]: gnome-session-binary[1212]: GnomeDesktop-WARNING: Failed to acquire idle monitor proxy: Timeout was reached
mrt 18 19:28:34 <computer_name> gnome-session-binary[1212]: GnomeDesktop-WARNING: Failed to acquire idle monitor proxy: Timeout was reached
mrt 18 19:28:34 <computer_name> gsd-usb-protect[1453]: Failed to get screen saver status: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code24: Timeout was reached
mrt 18 19:28:34 <computer_name> gsd-usb-protect[1453]: Failed to fetch USBGuard parameters: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
mrt 18 19:28:39 <computer_name> systemd[1]: systemd-hostnamed.service: Deactivated successfully.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Keyboard.service: start operation timed out. Terminating.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.MediaKeys.service: start operation timed out. Terminating.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Color.service: start operation timed out. Terminating.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Wacom.service: start operation timed out. Terminating.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Power.service: start operation timed out. Terminating.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Keyboard.service: Failed with result 'timeout'.
mrt 18 19:29:39 <computer_name> systemd[1126]: Failed to start GNOME keyboard configuration service.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME keyboard configuration target.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Color.service: Failed with result 'timeout'.
mrt 18 19:29:39 <computer_name> systemd[1126]: Failed to start GNOME color management service.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.MediaKeys.service: Failed with result 'timeout'.
mrt 18 19:29:39 <computer_name> systemd[1126]: Failed to start GNOME keyboard shortcuts service.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Wacom.service: Failed with result 'timeout'.
mrt 18 19:29:39 <computer_name> systemd[1126]: Failed to start GNOME Wacom tablet support service.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME color management target.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME keyboard shortcuts target.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME Wacom tablet support target.
mrt 18 19:29:39 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Power.service: Failed with result 'timeout'.
mrt 18 19:29:39 <computer_name> systemd[1126]: Failed to start GNOME power management service.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME power management target.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME Session.
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target GNOME Wayland Session (session: gnome).
mrt 18 19:29:39 <computer_name> systemd[1126]: Reached target Current graphical user session.
mrt 18 19:29:40 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Keyboard.service: Scheduled restart job, restart counter is at 1.
mrt 18 19:29:40 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Color.service: Scheduled restart job, restart counter is at 1.
mrt 18 19:29:40 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Wacom.service: Scheduled restart job, restart counter is at 1.
mrt 18 19:29:40 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.Power.service: Scheduled restart job, restart counter is at 1.
mrt 18 19:29:40 <computer_name> systemd[1126]: org.gnome.SettingsDaemon.MediaKeys.service: Scheduled restart job, restart counter is at 1.
mrt 18 19:29:40 <computer_name> systemd[1126]: Starting GNOME color management service...
mrt 18 19:29:40 <computer_name> systemd[1126]: Starting GNOME keyboard configuration service...
mrt 18 19:29:40 <computer_name> systemd[1126]: Starting GNOME keyboard shortcuts service...
mrt 18 19:29:40 <computer_name> systemd[1126]: Starting GNOME power management service...
mrt 18 19:29:40 <computer_name> systemd[1126]: Starting GNOME Wacom tablet support service...

AMD Ryzen 5 3600 and AMD Radeon RX 5700 XT here.

seth · 2024-03-18 23:14:05

https://bbs.archlinux.org/viewtopic.php … 0#p2158150
GDM by later accounts does NOT seem to be relevant (and the OP here uses it anyway) but either the simpledrm or other DRM related issues might be relevant as well as whether (G)DM and gnome use the same display sever (both wayland or both X11)

The timeouts are probably rather symptom than cause.

Edit:
@Captain Athelas, reg. your DM - no DE. A WM (recently back to fluxbox) and several tools (a lot of them TUI), shortcuts, scripts to handle mounts and outputs, a homebrew launcher (urxvt+zsh+xdotool) or sometimes rofi.
But what's more important is that you use the DE that suits you best, regardless of the peculiarities of its developers.
It's just that gnome has somewhat of a reputation for not being a very good citizen of the linux desktop and frequently breaks compatibility with everything, including itself…

Last edited by seth (2024-03-19 18:40:29)

dllmr · 2024-04-06 09:04:25

I also have the same issue. AMD GPU and I'm seeing the screensaver timeout messages. I can access a TTY if I run X11 but not Wayland.

I'm largely working around the issue by running LightDM rather than GDM. LightDM still gives the problem, but rarely enough that it's not too irritating.

Fwiw I've seen the issue on multiple AMD systems, but never on Nvidia. Clearly others are seeing the issue with Nvidia, but I wonder if AMD could be a factor that increases the likelihood.

seth · 2024-04-06 16:42:32

Random theory https://bbs.archlinux.org/viewtopic.php … 6#p2159426 - spurious timeout because the system time shifts.
Wasn't reflected in some other "gnome doesn't start" cases, but there're various reasons for that to begin with.

Does lightdm actually start a gnome wayland session?

Arch Linux

#1 2024-02-18 00:00:52

Gnome freezes upon login

#2 2024-02-19 04:19:39

Re: Gnome freezes upon login

#3 2024-02-19 06:41:09

Re: Gnome freezes upon login

#4 2024-02-19 09:16:09

Re: Gnome freezes upon login

#5 2024-02-19 10:34:36

Re: Gnome freezes upon login

#6 2024-02-19 17:07:35

Re: Gnome freezes upon login

#7 2024-02-19 17:20:00

Re: Gnome freezes upon login

#8 2024-02-19 17:25:01

Re: Gnome freezes upon login

#9 2024-02-19 17:33:39

Re: Gnome freezes upon login

#10 2024-02-19 17:36:26

Re: Gnome freezes upon login

#11 2024-02-19 17:51:07

Re: Gnome freezes upon login

#12 2024-02-19 21:52:12

Re: Gnome freezes upon login

#13 2024-02-20 00:18:16

Re: Gnome freezes upon login

#14 2024-03-02 12:52:56

Re: Gnome freezes upon login

#15 2024-03-02 17:09:46

Re: Gnome freezes upon login

#16 2024-03-02 18:26:51

Re: Gnome freezes upon login

#17 2024-03-02 19:03:28

Re: Gnome freezes upon login

#18 2024-03-02 21:29:19

Re: Gnome freezes upon login

#19 2024-03-03 07:04:48

Re: Gnome freezes upon login

#20 2024-03-03 13:10:29

Re: Gnome freezes upon login

#21 2024-03-14 20:48:46

Re: Gnome freezes upon login

#22 2024-03-18 18:50:06

Re: Gnome freezes upon login

#23 2024-03-18 23:14:05

Re: Gnome freezes upon login

#24 2024-04-06 09:04:25

Re: Gnome freezes upon login

#25 2024-04-06 16:42:32

Re: Gnome freezes upon login

Board footer