| Summary: | KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | flan_suse <windows2linux> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | major | CC: | kde |
| Priority: | NOR | ||
| Version: | 5.24.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Output of "systemd-inhibit --list" when KDE and SDDM are running.
Output of "systemd-inhibit --list" when KDE and SDDM are *NOT* running. journalctl when suspending with KDE 5.24 |
||
|
Description
flan_suse
2022-02-28 20:29:32 UTC
Please test with "systemctl suspend" If that behaves the same, the issue isn't our side. systemd-inhibit --list might also be useful (In reply to David Edmundson from comment #1) > Please test with "systemctl suspend" > > If that behaves the same, the issue isn't our side. > > systemd-inhibit --list might also be useful It gets more interesting. * While I am logged into a KDE session, even using "systemctl suspend" causes the same issue. AND... * If I logout of KDE (leaving only the SDDM login screen), then switch to TTY2 and issue "systemctl suspend", it's still affected by the same issue HOWEVER... * If I log out of KDE and stop the SDDM display manager ("systemctl stop sddm"), then switch to TTY2 and issue "systemctl suspend", the issue no longer exists: CPU is not running hot, and using my wireless keyboard or mouse properly wakes up from suspend So *without* KDE nor SSDM running, it behaves correctly again (regardless of which kernel I'm using). If KDE or SDDM is running, then even using "systemctl suspend" reproduces the same issue. Only when I stop SDDM and suspend, it will work correctly I will attach the outputs from "systemd-inhibit --list". The first text file is the output when logged into KDE. The second text file is the output when I stop SDDM. (I must also note that when I force the laptop to wake up when the bug is occurring, my wallpaper doesn't "stick" anymore. If I switch workspaces, the wallpaper will flicker and disappear.) Created attachment 147216 [details]
Output of "systemd-inhibit --list" when KDE and SDDM are running.
Output of "systemd-inhibit --list" when KDE and SDDM are running.
Created attachment 147217 [details]
Output of "systemd-inhibit --list" when KDE and SDDM are *NOT* running.
Output of "systemd-inhibit --list" when KDE and SDDM are *NOT* running.
Keep in mind when this bug occurs, my fans STOP. Monitor shut off (no signal). However, for some reason my CPU is heating up rapidly, since it's somehow still running, but without the cooling of the fans. I can attach a journalctl as well, but it appears to believe the suspend was successful. Created attachment 147231 [details]
journalctl when suspending with KDE 5.24
Notice there's a 3-minute gap in the log? That's how long I waited while the system was "suspended". I couldn't wake it up until I used the laptop's keyboard to "wake up" the system. (USB mouse and keyboard did not work.)
Yes, during that 3-minute period, the laptop got REALLY HOT, since the fans stopped, but apparently the CPU was still cooking.
This doesn't happen with KDE 5.23 (doesn't matter which kernel, nor which version of upower.)
(In reply to flan_suse from comment #6) > Notice there's a 3-minute gap in the log? To emphasize this point, for all intents and purposes the system *did* in fact "suspend". No activity logged for 3 minutes, until I forced it to "wake up" again. During this 3-minute period, using the USB mouse and keyboard would *NOT* wake up the laptop, even though it's *supposed* to (as it does in KDE 5.23) During this 3-minute period (of no logged activity, remember), the laptop's fans are completely off. Yet the CPU quickly gets hotter and hotter! (I can feel it almost hurt my finger when I touch the surface.) None of the above issue happens if with KDE 5.24: 1) I log out 2) I switch to TTY2 3) I stop the SDDM service 4) I issue "systemctl suspend" Then it will behave *properly*, as if I was using KDE 5.23. This is why I think it's related to KDE (and notably, the transition from 5.23 -> 5.24). I believe it has something to do with local user settings (configured during 5.23 and earlier), which cause a conflict with KDE 5.24's changes in handling external displays, settings, and power management. Reverting back to KDE 5.23 (regardless of kernel), always, 100%, resolves the issue. This might be upower after all. I'll keep on eye on things, and see what happens with upstream upower. (However, I did try with an earlier version of upower, and the same issue persisted.) https://bbs.archlinux.org/viewtopic.php?id=274292 Upstream upower and kernel, after all. (Fixed in kernel 5.17) |