サスペンドからのウェイクアップが成功した後、Ubuntu 20.04は常に再起動します
更新1：2020年4月30日
syslogに次のログが見つかりました（要旨リンクを参照）：
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ログが添付されました。
この奇妙な問題が発生しています。コンピューターが一時停止し、一時停止から正常に復帰できます。問題なくデスクトップにログインできます。しかし、1分ほどすると、コンピューターが突然再起動し、BIOS起動画面とデフォルトのブートマネージャー（私のマシンのWindowsブートマネージャー、GRUB in BIOSブートメニュー）。
再起動後、次に一時停止を試みるまで、コンピューターは正常に機能します。
lastの出力を次に示します（奇妙に見えますが、12:02と15:46の間に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/117411aa36263e65d4507a2fcecf699
もう1つは、以前の発生で、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オーバークロック設定が無効になるため、これは特に厄介です。
よろしくお願いします。
lsusbを実行して、デバイスが何であるかを把握します。
また実行：dmidecode | grep "0xa0"と出力を教えてください。
Nvidiaを使用していることを知るのに役立ちます。私はnvidia、suspend、およびhibernationで多くの問題を抱えてきました。 rootターミナルを開いてシステムからスクリプトを回避すると、問題に近づく可能性があります。
#Suspend-to-RAM
echo -n "deep" > /sys/power/mem_sleep
echo -n "mem" > /sys/power/state
これは、カーネルがサスペンド時に行うメインコードです。デバイスを再び起動します。再起動しない場合は、your/systemdの構成の一部が正しくありません。それをデバッグする方法についての次の説明をチェックすることもできます： kernel documentation