Created attachment 165092 [details] Journal of boot until it stop working SUMMARY If the screen is turn off and then the pc goes to sleep (only possible if the lid is closed because trying to use a shortcut to sleep cause pc screen to turn on), on lid open the screen is black and the pc is unusable (require a reboot). STEPS TO REPRODUCE 1. Trigger a shortcut to turn the screen off (to set in systemsettings) 2. Close the lid 3. Reopen the lid OBSERVED RESULT Almost always it is a black screen with no possibility of exit. It seem it fail to go to sleep and that cause problem (i think): gen 21 09:08:11 arch systemd-sleep[4976]: Failed to lock home directories: Unknown object '/org/freedesktop/home1'. EXPECTED RESULT The screen should turn on. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.7.0 Kernel Version: 6.7.0-arch3-1 (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS TUF Gaming A15 FA507NV_FA507NV ADDITIONAL INFORMATION I'm using the "acpi_backlight=native acpi_osi=linux" kernel parameters for getting brighness (and so turn off screen) to work.
The '/org/freedesktop/home1' line is not usually cause for concern, I got that too but can't reproduce your error. Well, except for the first time where I made it farther than your log and the kernel sleep message was reached, but somehow my device failed anyway. But since then, I've tried several times (with approx. 5.92.0 components) but keep waking up correctly. The posted logs were slightly confusing because they repeatedly say going to sleep/suspend without undoing that state, until I realized by looking at the timestamps that it's the same exact 1-2 pages of logs repeating. On its own though, the log doesn't really tell us much and barely even contains output by KDE components. Does "coredumpctl list" show any mentions of a "org_kde_powerdevil"? Otherwise we'd have to get you to raise your log levels to show anything useful (assuming it's Plasma-related).
Does this only happen when the screen is already off once you close & open the lid? So, if your desktop hasn't disabled the screen yet and you close & open the lid, does it work more reliably?
> Does this only happen when the screen is already off once you close & open the lid? > So, if your desktop hasn't disabled the screen yet and you close & open the lid, does it work more reliably? Not sure if I understand your question, but if you are asking if sleep work on its own (without turning off the screen) then yes it always work and never fail. I'll add the complete journalctl and the output of "coredumpctl list".
Created attachment 165231 [details] Complete journalctl
Created attachment 165232 [details] Output of "coredumpctl list"
I see something possibly related on NixOS, but with sleep on lid close config (power settings). When closing lid even with screen on and unlocked, or screen locked, or screen off, the system attempts to go to sleep, but can't. Instead, fans accelerate, like an infinite loop. Opening the lid shows black screen with keyboard still on (i.e. system didn't sleep), and it can't wake up. sysrq (which usually works) doesn't work here, and only a hard shutdown can turn the laptop off. Putting the laptop to sleep from kickoff or lockscreen (screen on) works as usual, while a `sleep 5 && systemctl suspend` on console, followed by lockscreen + esc (to turn screen off) also presents the problem, so it looks like the issue is trying to suspend with screen off. Ryzen 6900HS m + Radeon 6850M, if it matters. `journalctl -eb -1` shows the usual stuff in the end: > systemd-logind[2144]: Lid closed. > systemd-logind[2144]: The system will suspend now! > ModemManager[20361]: <msg> [sleep-monitor-systemd] system is about to suspend > kernel: r8169 0000:06:00.0 enp6s0: Link is Down > systemd[1]: Starting Pre-Sleep Actions... > systemd[1]: Starting TLP suspend/resume... > systemd[1]: pre-sleep.service: Deactivated successfully. > systemd[1]: Finished Pre-Sleep Actions. > systemd[1]: Finished TLP suspend/resume. > systemd[1]: Reached target Sleep. > systemd[1]: Starting System Suspend... > systemd-sleep[97413]: Failed to lock home directories: Unknown object '/org/freedesktop/home1'. > systemd-sleep[97413]: Performing sleep operation 'suspend'... > kernel: PM: suspend entry (s2idle)
PS: it seems to happen only when discrete gpu is turned on and/or external monitor connected. If external monitor is disconnected, dGPU is off and system is running on the Rembrandt 680M iGPU, closing lid suspends system and wakes up normally.
(In reply to André M from comment #7) > PS: it seems to happen only when discrete gpu is turned on and/or external > monitor connected. If external monitor is disconnected, dGPU is off and > system is running on the Rembrandt 680M iGPU, closing lid suspends system > and wakes up normally. For me it happens without discrete gpu and without external monitor connected.
It seem to be disappered for me. I don't know what solved it but now it works as expected (possibly connected to kernel or other software update).
Thanks for retesting. It does sound like something on the kernel (or at least systemd) level, so I'm glad it's resolved for you because I'm not sure how I would have approached it without being able to reproduce. André M, I figure your issue is still present. I'd say the fact that your logs made it to "kernel: PM: suspend entry (s2idle)" is a strong indicator that you're hitting a kernel or firmware issue - at that point, things are out of KDE's hands. If it's reproducible, you may find people from your Linux distro or (if self-compiled) the kernel bug tracker https://bugzilla.kernel.org/ that have a better sense about how to debug those low-level issues. I'd say make sure that you're running recent firmware/BIOS as provided by your laptop manufacturer, but you've probably already taken care of that. Given all that, I'm tempted to close this bug report as RESOLVED WORKSFORME. If you think that's the wrong call, feel free to reopen and shout at me.
Searching again for this issue, I got to this topic, and the solution there finally fixed the issue for me: https://bbs.archlinux.org/viewtopic.php?id=290523 > # echo 0 > /sys/power/pm_async