GNOME Bugzilla – Bug 769954
Freeze on screen timeout or logout/login with Wayland(mutter) but not weston
Last modified: 2021-07-05 13:46:45 UTC
Created attachment 333381 [details] Hardware devices On screen timeout (set at 5 minutes), the display blanks and enters "power saving" mode and then the entire computer is no longer responsive. Unable to change terminals (Ctrl-Alt-F1/2/3/4), and unable to SSH into computer from another working computer(no response from target machine). Numlock keypress does respond based on keyboard Numlock LED, but pressing the power button (set the 'hibernate') does nothing. Ctrl-Alt-Del does nothing, nor does Ctrl-Alt-Backspace. Only recourse is to hold down power button for a forced shutdown. I can easily trigger this behavior by 'locking' the currently logged in user. If I don't login at all, then after the display timeout the computer again freezes. Suspicion: Possible issue with DPMI and Wayland, but not weston. Work-around: If I specify my desktop to be GNOME and not GNOME-Wayland, everything works properly. After the specified 5 minutes, display blanks and enters power saving mode. Moving the mouse or pressing a key resumes the system and it prompts me for a password. Alternatives: After installing the weston compositor, I can login to 'weston'. The display will blank after timeout and I can easily resume. Unable to 'lock' the workstation using weston. Additional issues: If I set the screen timeout to 'Never', the screen still will blank after some period of inactivity and the computer will freeze. In addition, if I login first using GNOME (without Wayland), then logout and login with GNOME-Wayland, the computer simply freezes and never logs in. Logs: A dump of `journalctl -a -b -1` after system restart shows no messages around the time of the freeze. Hardware: Dell Dimension 8400, 2GB RAM Video: ATI Radeon X850 via DVI output, standard ATI drivers OS: Fedora 24 Kernel 4.6.5-300.fc24.i686
This sounds like a driver issue that is triggered by something mutter does and Xorg doesn't, since the whole system becomes unresponsive. If it'd be mutter that froze, it would still be possible to access via SSH. It'd be very interesting to know whether mutter from git master induces this behavior as well, since it changes how the KMS API is used, which I would assume is the relevant difference between GNOME and GNOME-Wayland. The actual suspending I assume is the same (by the same external tool). Do you have any other kernel versions to test with as well? Other things that could help is enabling all debug logging in mutter and then reproduce the issue
I did more extensive testing. On the same computer, using Fedora 23, the behavior is not present. I can select 'GNOME - Wayland' and it will lock the screen after time out and wake up properly with mouse movement or key press. However, on F24, both kernel 4.6.5 and 4.6.4-301.fc24.i686 exhibit this problem. Further testing, however, shows that the system does not always hang. One time, the display entered power saving state and was unable to be woken, but the system did respond to SSH and I was able to enter the computer via SSH. I was then able to restart GDM using "dbus-send --type=method_call --print-reply --dest=org.gnome.Shell /org/gnome/Shell org.gnome.Shell.Eval string:'global.reexec_self()'" from SSH as recommended from http://askubuntu.com/questions/455301/how-to-restart-gnome-shell-after-it-became-unresponsive-freeze/496999. This 'woke' up the computer and I was able to interact with it normally. I then enabled debugging options, and now I'm suspicious for a timing issue. When MUTTER_DEBUG was enabled, if I rapidly logged in and then attempted to open a terminal GNOME-Desktop would crash and dump me back to the login screen. The log file, however, didn't show any activity beyond my login. Filtering journal entries for 'gnome-shell' reveals multiple mutter-WARNING regarding 'window %h already in stack' (not sure if relevant), followed by the more ominous ANOM_ABEND sig=11 then seg fault at e4e1c0, error 4, in libc-2.23.so[base+1c8000]. In between there were additional Gjs-WARNING regarding Smartcard (for which I don't have a reader so I believe that can be safely ignored). Now, if I reproduced the steps but waited some time before launching terminal, terminal runs fine without any segmentation faults (but the lock-up on timeout behavior remains). Suspicious for possible bad memory, I then ran memtester for 1000MB (I have a 2GB RAM machine with 2GB swap), and it while running the screen timer activated. This time, I was able to resume properly if I move the mouse as the screen _starts_ to fade, i.e. before the full timeout occurs. I didn't see any errors, but then the screen idle timer activated again and this time I didn't catch it in time. Interestingly enough, I was able to SSH into the computer when the screen was in power saving mode, but the moment I moved the mouse and pressed keys, SSH failed to respond and the computer froze. TL;DR: The problem is not present in FC23, only in FC24 on both 4.6.5 and 4.6.4, but does not always freeze the entire kernel. When monitor entores power saving state, the kernel is not frozen. Upon attempting to wake, the kernel freezes before waking. Debugging didn't emit any additional information in the logs after the freeze, but review of journal shows possible timing-associated segmentation fault if 'Terminal' is launched immediately after login (not directly related to the freeze, as far as I can tell). I'm beginning to suspect the problem is with my older hardware and slow performance exposing some timing issue. Since GNOME works fine, I will stick with GNOME for now without Wayland.
Created attachment 333440 [details] Journal entries filtered for 'gnome-shell'
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.