从挂起成功唤醒后，Ubuntu 20.04 总是重新启动

Question

更新 1：2020 年 4 月 30 日

在syslog（参见 Gist 链接）中找到以下日志：

Apr 30 15:56:34 aurora-r8-linux kernel: [  607.945292] ACPI: Waking up from system sleep state S3
Apr 30 15:56:34 aurora-r8-linux kernel: [  608.507372] snd_hda_intel 0000:01:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x005f2f04
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.084330] usb usb1: root hub lost power or was reset
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.084335] usb usb2: root hub lost power or was reset
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088035] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [DRQL] at bit offset/length 136/8 exceeds size of target Buffer (128 bits) (20190816/dsopcode-198)
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088038] No Local Variables are initialized for Method [DSRS]
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088039] Initialized Arguments for Method [DSRS]:  (2 arguments defined for method invocation)
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088039]   Arg0:   00000000d64c2208 <Obj>           Buffer(16) 47 01 F8 03 FF 03 00 08
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088042]   Arg1:   00000000f4b3cffb <Obj>           Integer 0000000000000000
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088044] ACPI Error: Aborting method \_SB.PCI0.LPCB.SIO1.DSRS due to previous error (AE_AML_BUFFER_LIMIT) (20190816/psparse-529)
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088047] ACPI Error: Aborting method \_SB.PCI0.LPCB.UAR1._SRS due to previous error (AE_AML_BUFFER_LIMIT) (20190816/psparse-529)
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088050] serial 00:02: activation failed
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088052] PM: dpm_run_callback(): pnp_bus_resume+0x0/0xa0 returns -5
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088053] PM: Device 00:02 failed to resume: error -5
Apr 30 15:56:34 aurora-r8-linux kernel: [  609.096400] sd 0:0:0:0: [sda] Starting disk

特别有趣的是：

Apr 30 15:56:34 aurora-r8-linux kernel: [  609.088053] PM: Device 00:02 failed to resume: error -5

这可能与问题有关吗？我如何找出是什么设备00:02？什么是error -5？

---

TL;DR：Ubuntu 从挂起状态唤醒后大约 1 分钟重新启动（能够成功登录到桌面）。syslog附上日志。

我遇到了这个奇怪的问题，我的计算机能够挂起，也能够成功地从挂起中唤醒。我可以毫无问题地登录到桌面。但是大约一分钟后，我的计算机会突然重新启动，带我通过 BIOS 启动屏幕和默认启动管理器（我的机器的 Windows 启动管理器，除非我在 BIOS 启动菜单中选择 GRUB）。

重新启动后，我的计算机将正常运行，直到我下次尝试挂起它为止。

这是last( 看起来有点奇怪，不知道为什么12:02在15:46and之间有一个条目16:02：

?  ~ last                   
okamayan :1           :1               Thu Apr 30 16:02   still logged in
reboot   system boot  5.4.0-28-generic Thu Apr 30 12:02   still running
okamayan :1           :1               Thu Apr 30 15:46 - crash  (-3:44)
reboot   system boot  5.4.0-28-generic Thu Apr 30 11:46   still running

syslog相关时间段的日志（我相信重启发生在15:46-左右16:02）：https : //gist.github.com/okamayana/117411aa36263e65d4507a2fcecf6990

另一件事是，在以前的事件中，我能够在 中找到以下日志语句syslog：

Apr 29 09:41:52 aurora-r8-linux boltd[2279]: udev: found 0 domain
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: manager: acquired power guard '1'
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: udev: enumerating devices
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: power: guard '1' for 'boltd' deactivated
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: power: shutdown scheduled (T-20.00s)
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: power: state changed: supported/wait
Apr 29 09:41:52 aurora-r8-linux dbus-daemon[830]: [system] Successfully activated service 'org.freedesktop.bolt'
Apr 29 09:41:52 aurora-r8-linux systemd[1]: Started Thunderbolt system service.
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: power: state changed: supported/on
Apr 29 09:41:52 aurora-r8-linux boltd[2279]: power: guard '2' for 'fwupd' active

我已经删除并清除了bolt，但问题仍然存在！值得注意的是boltd日志不再出现，所以我怀疑这是原因。我可能只是重新安装它。不过，我没有任何 Thunderbolt 设备（甚至端口，不确定）。

如果有帮助，我的系统是 Alienware Aurora R8 桌面，带有 i5-9600K 和 Nvidia RTX 2070（我使用的是 Nvidia 闭源驱动程序）。

任何帮助深表感谢。我找不到任何突出的东西syslog。我应该查看dmesg或任何其他日志吗？

我可以无休止地生活，但我想看看我是否可以让它发挥作用。这尤其令人讨厌，因为像这样的意外关机总是会禁用 BIOS 超频设置。

再次提前致谢。

Answer 1

了解您正在使用 nvidia 会有所帮助。我在 nvidia、挂起和休眠方面遇到了很多问题。如果您通过打开根终端来绕过系统中的任何脚本，您可能会更接近您的问题：

#Suspend-to-RAM
echo -n "deep" > /sys/power/mem_sleep 
echo -n "mem" > /sys/power/state

这是内核在挂起时执行的主要代码。再次唤醒您的设备。如果它没有重新启动，则说明您/systemd 的配置中的某些内容不正确。您可能还想查看以下有关如何调试它的描述： 内核文档

Answer 2

运行lsusb以了解该设备是什么。

同时运行：dmidecode | grep "0xa0"并让我们知道输出是什么。