Hi,
I have some problem with my laptop freezing when the screen is blank. Basically every time I lock the screen (or close the lid) my laptop freezes and cannot be woken up anymore. The screen will stay black regardless of which buttons I press. The only way to recover is to press and hold the power button to shut off the computer. Obviously, that's not very convenient. Even more so as I cannot even bring my laptop to someone else's desk to quickly show them something; I first need to reboot at their place. My coworkers are already making fun of linux and how it is not suitable for laptop use and maybe I should consider switching to Microsoft Windows instead. They say: "Well, it is open source, so why don't you just go ahead and fix the problem yourself?" I wish I could, but I do not even know where the issue is. journalctl seems to be unhelpful (see below of the output right before the hard reboot). So, any ideas of how to debug and hopefully solve this problem? Thanks a lot!
Aug 27 10:36:57 localhost systemd[6304]: Started GNOME Media keys handling. Aug 27 10:36:57 localhost systemd[6304]: Reached target GNOME Media keys handling. Aug 27 10:36:57 localhost systemd[6304]: Reached target GNOME Session. Aug 27 10:36:57 localhost systemd[6304]: Reached target GNOME Wayland Session (session: gnome). Aug 27 10:36:57 localhost systemd[6304]: Reached target Current graphical user session. Aug 27 10:36:57 localhost systemd[6304]: Condition check resulted in GNOME Initial Setup being skipped. Aug 27 10:36:57 localhost systemd[6304]: Condition check resulted in GNOME Welcome Tour being skipped. Aug 27 10:36:57 localhost libcanberra-login-sound.desktop[7612]: Failed to play sound: File or data not found Aug 27 10:36:57 localhost systemd[6304]: gnome-launched-libcanberra-login-sound.desktop-7612.scope: Succeeded. Aug 27 10:36:57 localhost gsd-media-keys[7523]: Failed to grab accelerator for keybinding settings:rfkill Aug 27 10:36:57 localhost gsd-media-keys[7523]: Failed to grab accelerator for keybinding settings:playback-repeat Aug 27 10:36:57 localhost gsd-media-keys[7523]: Failed to grab accelerator for keybinding settings:playback-random Aug 27 10:36:57 localhost gsd-media-keys[7523]: Failed to grab accelerator for keybinding settings:hibernate Aug 27 10:36:57 localhost nextcloud[7608]: QSocketNotifier: Can only be used with threads started with QThread Aug 27 10:36:57 localhost gnome-software[7594]: enabled plugins: desktop-categories, fwupd, os-release, packagekit, packagekit-local, packagekit-offline, packagekit-proxy, packagekit-refresh, packagekit-upgrade, packagekit-url-to-app, appstream, fedora-pkgdb-collections, desktop-menu-path, fedora-langpacks, flatpak, hardcoded-blacklist, hardcoded-popular, modalias, packagekit-refine, rewrite-resource, odrs, packagekit-history, provenance, repos, systemd-updates, generic-u> Aug 27 10:36:57 localhost gnome-software[7594]: disabled plugins: dummy Aug 27 10:36:57 localhost systemd[6304]: GNOME session X11 services is not active. Aug 27 10:36:57 localhost systemd[6304]: Dependency failed for GNOME XSettings. Aug 27 10:36:57 localhost systemd[6304]: gsd-xsettings.target: Job gsd-xsettings.target/start failed with result 'dependency'. Aug 27 10:36:57 localhost systemd[6304]: Starting GNOME XSettings... Aug 27 10:36:57 localhost ibus-daemon[7357]: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes. Aug 27 10:36:57 localhost systemd[6304]: dbus-:1.2-org.freedesktop.portal.IBus@0.service: Succeeded. Aug 27 10:36:57 localhost systemd[6304]: Started dbus-:1.2-org.freedesktop.portal.IBus@1.service. Aug 27 10:36:57 localhost gnome-shell[7885]: The XKEYBOARD keymap compiler (xkbcomp) reports: Aug 27 10:36:57 localhost gnome-shell[7885]: > Warning: Unsupported maximum keycode 569, clipping. Aug 27 10:36:57 localhost gnome-shell[7885]: > X11 cannot support keycodes above 255. Aug 27 10:36:57 localhost gnome-shell[7885]: > Internal error: Could not resolve keysym Invalid Aug 27 10:36:57 localhost gnome-shell[7885]: > Error: Key <LFSH> added to map for multiple modifiers Aug 27 10:36:57 localhost gnome-shell[7885]: > Using Lock, ignoring Shift. Aug 27 10:36:57 localhost gnome-shell[7885]: Errors from xkbcomp are not fatal to the X server Aug 27 10:36:58 localhost systemd[6304]: Started GNOME XSettings. Aug 27 10:36:58 localhost gnome-shell[7235]: GNOME Shell started at Thu Aug 27 2020 10:36:56 GMT+0900 (Japan Standard Time) Aug 27 10:36:58 localhost gnome-shell[7235]: Registering session with GDM Aug 27 10:36:58 localhost gsd-color[7506]: failed to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/xrandr_Eizo_Nanao_Corporation_EV2785_25537038_gdm_42 Aug 27 10:36:58 localhost gsd-color[7506]: failed to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/xrandr_BOE_gdm_42 Aug 27 10:36:58 localhost gnome-software[7594]: not handling error failed for action get-updates-historical: failed to build result for e234811a0b3925f31157d034477df3bc368a3254
On 2020-08-27 10:24, Jan-Erik Wichmann wrote:
I have some problem with my laptop freezing when the screen is blank. Basically every time I lock the screen (or close the lid) my laptop freezes and cannot be woken up anymore. The screen will stay black regardless of which buttons I press. The only way to recover is to press and hold the power button to shut off the computer. Obviously, that's not very convenient. Even more so as I cannot even bring my laptop to someone else's desk to quickly show them something; I first need to reboot at their place. My coworkers are already making fun of linux and how it is not suitable for laptop use and maybe I should consider switching to Microsoft Windows instead. They say: "Well, it is open source, so why don't you just go ahead and fix the problem yourself?" I wish I could, but I do not even know where the issue is. journalctl seems to be unhelpful (see below of the output right before the hard reboot). So, any ideas of how to debug and hopefully solve this problem? Thanks a lot!
I only have one laptop and it has been working fine for years. One thing to try first is to edit /etc/systemd/logind.conf to change HandleLidSwitch to
HandleLidSwitch=ignore
I don't recall if a reboot is needed for the change to take effect.
HandleLidSwitch=ignore
well, that's a crude workaround. It does permit me to carry around my laptop for short distances, but longer walks are no good because it will continue to be powered on and the fans need to get fresh air.
So still looking for a solution which solves the underlying issue: When the screen gets locked and the monitor turns off as a result, the computer will freeze. Quite aweful. I cannot even suspend my laptop, so sometimes I just leave it running and wasting energy just so that I can continue working in the morning without having to restart everything.
On 2020-08-27 12:07, laolux laolux wrote:
HandleLidSwitch=ignore
well, that's a crude workaround. It does permit me to carry around my laptop for short distances, but longer walks are no good because it will continue to be powered on and the fans need to get fresh air.
So still looking for a solution which solves the underlying issue: When the screen gets locked and the monitor turns off as a result, the computer will freeze. Quite aweful. I cannot even suspend my laptop, so sometimes I just leave it running and wasting energy just so that I can continue working in the morning without having to restart everything.
I suppose I misunderstood your requirement.
It sounds as if you want your laptop to hibernate or suspend and then resume where you left off when the lid is opened and the power button pressed?
You can try
HandleLidSwitch=hibernate
You may also want to test the ability of your laptop to suspend vs hibernate by testing
sudo systemctl hibernate sudo systemctl suspend
and
sudo systemctl hybrid-sleep
from the command line
Thanks for your suggestions. hibernate is not supported (as expected) and suspend reliably crashes the system.
I think my issues come from the screen locking: When I lock my screen, I can unlock it within about 2 seconds. If I leave my screen locked for about 10 seconds or more, then I can never unlock it again. Maybe it is related to the display being turned off when the screen is being locked? But how would I test such?
Thanks for your help!
On 8/26/20 7:24 PM, Jan-Erik Wichmann wrote:
I have some problem with my laptop freezing when the screen is blank. Basically every time I lock the screen (or close the lid) my laptop freezes and cannot be woken up anymore. The screen will stay black regardless of which buttons I press. The only way to recover is to press and hold the power button to shut off the computer.
What is the graphics device? If NVidia, are you using the proprietary drivers?
Is this a recent problem? Did it used to work? Have you tried booting an earlier kernel version or trying a live boot with a different kernel?
Try running "systemctl suspend". Does that work and resume?
in Gnome settings, under Power, turn off the screen blanking and under Privacy->Screen Lock, disable screen lock. Does closing the lid work now?
What is the graphics device? If NVidia, are you using the proprietary drivers?
The graphics card is from intel: VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
Is this a recent problem? Did it used to work? Have you tried booting an earlier kernel version or trying a live boot with a different kernel?
No, the problem persists for some months now. It used to work with Fedora 31, not sure which kernel. I tried the last couple of 5.7 kernels from Fedora 32 as well as the new 5.8, to no avail. I had some issues of trying to lock the screen in live images, will try that again.
Try running "systemctl suspend". Does that work and resume?
It seems to suspend (fan stopped), but I can never resume.
in Gnome settings, under Power, turn off the screen blanking and under Privacy->Screen Lock, disable screen lock. Does closing the lid work now?
Closing the lid is fixed with @Ed Greshko's help of setting HandleLidSwitch=ignore in etc/systemd/logind.conf. But that means the computer is running when the lid is closed -> not good to put in my bag and transport somewhere.
On 8/26/20 11:12 PM, laolux laolux wrote:
in Gnome settings, under Power, turn off the screen blanking and under Privacy->Screen Lock, disable screen lock. Does closing the lid work now?
Closing the lid is fixed with @Ed Greshko's help of setting HandleLidSwitch=ignore in etc/systemd/logind.conf. But that means the computer is running when the lid is closed -> not good to put in my bag and transport somewhere.
Right, so put that back the way it was and try those settings.
It sounds like there's a kernel bug with the Intel graphics, so it might be best to file a bug on the upstream kernel bugzilla. Narrowing it down to the last known good kernel would be really helpful though.
On 8/26/20 11:12 PM, laolux laolux wrote:
Right, so put that back the way it was and try those settings.
It sounds like there's a kernel bug with the Intel graphics, so it might be best to file a bug on the upstream kernel bugzilla. Narrowing it down to the last known good kernel would be really helpful though.
Well, that might not be so easy. What shall I report? I have no interesting journalctl output nor other clues. Reporting to Red Hat bugzilla certainly did not draw any attention: https://bugzilla.redhat.com/show_bug.cgi?id=1849025
I just tried live images of Fedora 31 and Fedora 32. Fedora 32 live image is bad, both suspend and lock screen crash reliably. Fedora 31 live image is different. Suspend works and I can wake up, reliably (worked 8 out of 8 times). However, lock does not work well. I can unlock after 10 seconds (8 out of 8 times), but I cannot unlock anymore after 20 seconds (3 out of 3 times). I will try Fedora 30 next.
OK, Fedora 30 is pretty much the same as Fedora 31. Suspend works, lock screen only for a few seconds. However, this situation would be fine for me. Suspend is more important to me then lock screen. So if you have any ideas of how to debug the issue, I would really appreciate it!
On Thu, 2020-08-27 at 07:32 +0000, laolux laolux wrote:
However, lock does not work well. I can unlock after 10 seconds (8 out of 8 times), but I cannot unlock anymore after 20 seconds (3 out of 3 times).
Do you have different suspend options in the BIOS (or UEFI)? It could be that you can change a setting so that the laptop still provides enough power to its RAM during suspend that it can resume.
Hibernation could be a problem if you don't have a large enough swap partition, or swap file, or don't have a kernel options specifying which swap to resume from.
On Thu, 2020-08-27 at 07:32 +0000, laolux laolux wrote:
Do you have different suspend options in the BIOS (or UEFI)? It could be that you can change a setting so that the laptop still provides enough power to its RAM during suspend that it can resume.
Hibernation could be a problem if you don't have a large enough swap partition, or swap file, or don't have a kernel options specifying which swap to resume from.
Well, I do not think that lock screen should invoke any power saving options as programs are expected to keep running. Yet, locking the screen freezes my system.
I actually investigated further and found that locking the screen crashes my fedora 32 for any kernel from 5.4 to 5.8. About 20 seconds after locking the screen the computer is dead and even breaks existing ssh connections. Funnily enough suspend works up to kernel 5.7.5, I just need to make sure to immediately enter my password. From 5.7.6 onward everything is broken.
However, I think I tracked the problem to the i915 kernel module. Setting `i915.modeset=0` in grub lets my computer lock the screen and continue working. Also suspend works on all kernels, including wakeup. Only issue with `i915.modeset=0` is that once the srceen turns black it will stay that way until reboot. But I can enter my password to unlock the desktop and issue commands, just need to remember to do everything without seeing -> no typos please ;-)
So I reported it upstream as bug in the intel linux driver: https://gitlab.freedesktop.org/drm/intel/-/issues/2404 Let's see if anything comes from that.
-
Ed Greshko -
Jan-Erik Wichmann -
laolux laolux
-
Samuel Sieb -
Tim