Macbook Air 上的 Kubuntu 20.04 可以正常挂起,但每次唤醒都需要太多时间,大约 20 秒。
这似乎是正常挂起/睡眠的情况,而不是休眠,因为systemctl suspend
会触发相同的行为。
跑步,醒来然后跑步
journalctl -b --since "1min ago"
我明白了这(在 Pastebin 上)。那里没有提到冬眠。
至于内存和交换,我认为有足够的 RAM:
~$ free -h
total used free shared buff/cache available
Mem: 3,8Gi 703Mi 1,7Gi 162Mi 1,4Gi 2,7Gi
Swap: 2,0Gi 440Mi 1,6Gi
答案1
简短回答:
在 22.04 中:
echo deep | sudo tee -a /sys/power/mem_sleep
如果上述操作在 22.04 中不起作用或者在 22.10、23.04 或更高版本中出现这种情况:
echo s2idle | sudo tee -a /sys/power/mem_sleep
该解决方案可能会在内核更新后甚至重启后停止工作,因此可以在重启时运行包含所需命令的脚本。
第一部分有点矛盾,因为deep
应该总是触发长唤醒和s2idle
短唤醒,正如所说这里。我的 22.04 中可能存在一些错误,至少有时显然会出现相反的情况。
长答案:
发布这个问题后不久,我偶然发现了一个似乎有效的解决方案:在 ubuntuforums 上这里,并给出更多建议来回应,这里。
我不太明白这是怎么回事,可能涉及一个错误。那篇文章说解决方案是从 切换/sys/power/mem_sleep
到s2idle
。deep
我不清楚这一点,因为查找该文件时,它只包含这一行:
s2idle [deep]
意思就是deep
已被选中(!!) — 更不用说,如上所述,相反的行为是可以预料的。 —
在询问之后我明白了命令的作用这里。
正如最初的 ubuntuforums 评论中所指示的,我没有尝试更改该文件,但我使用了该命令(也基于第二条评论):
echo deep | sudo tee -a /sys/power/mem_sleep
再次查看该文件,它似乎没有变化。即使重新启动后它仍然如此s2idle [deep]
,但此时从挂起状态唤醒是瞬间完成的!(据我回想起来,这与预期正好相反:deep
应该意味着长时间的唤醒!)
看起来该文件并没有被该命令改变,但是某物已更改 — 无论是否与该文件相关。
将其更改[s2idle] deep
为相应的命令echo s2idle | sudo tee -a /sys/power/mem_sleep
(为了稍微调查一下,如与链接问题相关的评论中讨论的那样),20 秒长时间唤醒问题确实解决了不是再现。
也许是有一些我无法追踪的错误在起作用。
经过一些内核更新后,最初的问题再次出现,并以相同的方式修复。(实际上,该文件/sys/power/mem_sleep
已经是命令应该触发的形式,但后者仍然是必要的。)
更新(2022 年 10 月 24 日):
在新的更新之后,上述解决方案不再起作用 - 但相反的解决方案却起作用了:echo s2idle | sudo tee -a /sys/power/mem_sleep
,这相当于做了相反我的消息来源促使我这么做。
那一刻我觉得这很奇怪,但现在我明白了,事实上这一直是预期的行为:之前发生的事情很奇怪而且有缺陷,而新的更新已经修复了这个问题;s2idle
应该可以证明快速唤醒。
更新到“正常”的 22.10 版本后,问题似乎暂时得到解决,而文件/sys/power/mem_sleep
似乎已重置为deep
。但 20 秒唤醒延迟问题再次出现,并已按照上述更新 2 中所述进行修复。在全新安装 Kubuntu 22.10 后再次确认:在忍受了这个问题一个月后(只是为了看看是否可以用其他方式修复),第一个命令没有帮助,第二个命令有帮助(2023 年 2 月)。
由于该问题仍然存在(例如在 23.04 - 并且在更新之间相当频繁地重新出现),我已经建立了一个更快速的程序来从应用程序启动器运行该命令,创建以下fix_suspend
形式的脚本文件:
#!/bin/sh
echo s2idle | sudo tee -a /sys/power/mem_sleep
以及包含该行的文件~/.local/share/applications/Fix suspend.desktop
(适用于 Plasma):
Exec=pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true /path/to/fix_suspend
过了一会儿,解决方案在重启后停止工作,所以我不得不让脚本在重启时运行,如开头的简短回答中所示。