「電源管理/復帰トリガー」の版間の差分

2023年12月28日 (木) 13:01時点における最新版

復帰トリガー (ウェイクアップトリガー) とは、ハードウェアの任意の省電力状態からシステムを復帰させることのできるイベント要因です。自明な例としては、電源ボタンやスリープボタン、Wake-on-LAN 機能、ノートパソコンの蓋のスイッチがあります。復帰トリガーは、以下に挙げる様々なカーネルインターフェイスにより制御できます。すべての可能なトリガーをカバーする統一されたインターフェイスは存在しません。

1 復帰トリガーインターフェイス
2 永続的な設定
- 2.1 systemd によるワンタイムな方法
- 2.2 udev によるイベント駆動の方法
3 トラブルシューティング
- 3.1 デバイスやバスのツリーを一覧表示する
- 3.2 サスペンドからすぐに復帰する
  - 3.2.1 NVIDIA ドライバ
  - 3.2.2 nouveau ドライバ

復帰トリガーインターフェイス

/proc/acpi/wakeup

/proc/acpi/wakeup ファイルを読み出すと、ACPI に登録されているウェイクアップ要因のリストが得られます。利用可能であれば、対応する sysfs も得られます。Device 列のエントリをそのファイルに書き込めば、状態を切り替えることができます。例えば、ラップトップを開いたときの復帰を無効化するには:

# echo "LID" > /proc/acpi/wakeup

/sys/module/acpi/parameters/ec_no_wakeup

このファイルは ACPI カーネルモジュールオプション ec_no_wakeup の値を表しています。このオプションは、システムが suspend-to-idle (s2idle) 電源状態にあるときに組み込みコントローラからの復帰トリガーを渡すかどうかを制御します [1]。最近のノートパソコンでは、一部のケースで組み込みコントローラの復帰によりバッテリーの過剰な消耗を引き起こすことがあります。

/sys/devices/

復帰をサポートする sysfs デバイスには、デバイスの power サブディレクトリ内の wakeup ファイルがそれぞれ含まれています。このファイルには、復帰トリガーの状態が含まれ、書き込むこともできます。バスコントローラとエンドポイントデバイスは、システムを復帰させることができる可能性があります。例えば、USB コントローラ (バス) からの復帰を無効化するには:

# echo "disabled" > /sys/bus/usb/devices/usb1/power/wakeup

コントローラの設定に関わらず、トリガーが有効化されていれば、エンドポイントデバイスはデバイスを復帰させることができるはずです。しかし、これはハードウェア依存である可能性があります。

sysfs で PowerTOP インターフェイスをプログラムしてください。ただし、/sys/class/net/ と /sys/bus/usb/devices/ (/sys/devices/ へのシンボリックリンクを含みます) を読み出しても、ネットワーキングデバイスと USB デバイスの復帰トリガーしか得られません。

/sys/class/wakeup/*

/sys/class/wakeup ディレクトリにほぼすべての復帰トリガーがあります。このディレクトリには、関連するすべてのデバイスへのシンボリックリンクを含みます。サブディレクトリを見れば、利用可能な復帰トリガーを探すのに便利です。一部のトリガーは仮想デバイスに対応している可能性があります。一方、ハードウェア関連の復帰トリガーは、以下のファイルのうち少なくとも1つが含まれています:

/sys/class/wakeup/*/device/physical_node/power/wakeup
/sys/class/wakeup/*/device/power/wakeup

/sys/class/wakeup 内の復帰トリガーのいくつかは、以下のファイルが存在する暗号化された /proc/acpi/wakeup 名へのリンクを提供します:

/sys/class/wakeup/*/device/path

永続的な設定

ワンタイムな方法は、/proc/acpi/wakeup の状態や acpi.ec_no_wakeups カーネルパラメータを設定するには十分なはずです。udev を用いるイベント駆動のアプローチは、sysfs デバイスを設定する際に信頼性の高い方法です。

systemd によるワンタイムな方法

ec_no_wakeups ACPI カーネルモジュールオプションは、この記事で説明されているように起動時に設定できます。sysfs の値を起動時に設定する標準的な方法は systemd サービスです (例えばこのトラブルシューティングの場合のように)。他にも、/proc/acpi/wakeup 用の systemd ベースのマネージャとして wakeup-triggers^AUR があります。

一部のシステムは、電源状態の遷移時にいくつかの ACPI 復帰トリガーを上書きする可能性があります (これは機能というよりバグです)。ハードウェアがトリガーを上書きするタイミングが予測可能な場合、適切な systemd ユニットによりこの問題を解決することができます。sleep.target は、すべてのサスペンド状態をカバーする汎用 target で、この問題を解決するのに役立つかもしれません。しかし、汎用の wakeup.target は存在しません [2]。

この方法は、常に接続されている sysfs デバイスに対してのみ、確実に動作します。

udev によるイベント駆動の方法

udev ルールによる復帰トリガーの状態設定は、復帰トリガーを持つデバイスが接続されている時であれば常に動作するイベント駆動の方法です。重要なのは、ルールで新しいデバイスの追加を検出し (ACTION=="add")、ATTR{power/wakeup}="disabled" で復帰トリガーの状態を設定することです。この設定をハードウェアがリセットしてしまう場合、udev はデバイスの変更のたびにルールを再適用してこの問題の回避を試みることができます (ACTION=="add|change")。sysfs で見つかった特定のデバイスにマッチする利用可能なパラメータとデバイスツリーは、udevadm info -q all -a /sys/devices/... を使って得られます。

一般的な例としては、Logitech Unifying USB があります。このデバイスの復帰トリガーはデフォルトで有効になっているはずです。これが気に入らない場合、udev ルールで解決できるかもしれません:

/etc/udev/rules.d/logitech-unifying.rules

ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="disabled"

逆に、必要なトリガーを有効化する場合については udev の記事で説明されています。

udev はデバイス列挙の初期にトリガーするので、復帰トリガーを上記の方法で無効化すると、無効化したトリガー (の一部?) が /sys/class/wakeup にリストされません。これは、起動時にデバイスが存在していたかどうかに依存しているかもしれませんが、さらなる解明が必要です。

トラブルシューティング

デバイスやバスのツリーを一覧表示する

これらの補助コマンドは、特定のシステムにあるすべての復帰トリガーを把握したい時や、udev ルールを記述したり、一般的な復帰ソースのトラブルシューティングをしたりする時に便利です:

# lshw -businfo -numeric
# lspci -DPPnn
# lsusb -tvv

サスペンドからすぐに復帰する

LynxPoint や LynxPoint-LP チップセットが搭載された一部の Intel Haswell システムにおいて、サスペンドからすぐに復帰してしまうと報告されています。これは、BIOS の問題のある ACPI 実装と、起動時に xhci_hcd モジュールが ACPI イベントを解釈する方法に関連しています。解決策として、影響を受けるシステムは (XHCI_SPURIOUS_WAKEUP という名前の) ブラックリストにケースバイケースで追加されています [3]。

サスペンド中に USB デバイスを接続したときなどに ACPI の復帰トリガーが有効になって、即座に復帰してしまうことがあります。ブラックリストに追加されるまで一時的な応急処置としては復帰トリガーを無効化する方法があります。以下の設定で USB による復帰を無効化することができます [4]。

現在の設定を確認するには:

$ cat /proc/acpi/wakeup

Device  S-state   Status   Sysfs node
...
EHC1      S3    *enabled  pci:0000:00:1d.0
EHC2      S3    *enabled  pci:0000:00:1a.0
XHC       S3    *enabled  pci:0000:00:14.0
...

問題のデバイスは EHC1、EHC1、XHC (USB 3.0) です。状態を変更するには root としてデバイス名をファイルに echo してください:

# echo EHC1 > /proc/acpi/wakeup
# echo EHC2 > /proc/acpi/wakeup
# echo XHC > /proc/acpi/wakeup

上記のコマンドでサスペンドが再度機能するようになるはずです。ただし、設定は一時的なものなので起動するたびに設定し直す必要があります。自動化したい場合は systemd-tmpfiles を見てください。この問題に対する利用可能な解決策は BBS スレッドを見てください。

B550i Aorus や B550 AORUS ELITE V2 などの Gigabyte のマザーボードでは、NVMe ドライブへの GPP ブリッジがサスペンドからすぐに復帰する原因になる場合があります。GPP0 の状態を disabled に設定することでこの問題を解決できる場合があります:

# echo GPP0 > /proc/acpi/wakeup

NVIDIA ドライバ

NVIDIA のプロプライエタリドライバをインストールすると、サスペンドとハイバネートができなくなることがあります。そのようなケースでは、システムログに以下のメッセージが残ることがあります:

kernel: NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
kernel: PM: pci_pm_suspend(): nv_pmops_suspend+0x0/0x20 [nvidia] returns -5
kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -5
kernel: nvidia 0000:01:00.0: PM: failed to suspend async: error -5

NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持するを参照してください。

nouveau ドライバ

nouveau ドライバを使用している場合、サスペンドから即座に復帰してしまう原因はドライバのバグかもしれません (nouveau ドライバは GPU のサスペンドを妨げてしまうことがあります)。回避策は、スリープする直前に nouveau カーネルモジュールをアンロードして、復帰した時に再びロードすることです。これを行うには、以下のスクリプトを作成してください:

/usr/lib/systemd/system-sleep/10-nouveau.sh

#!/bin/bash

case $1/$2 in
  pre/*)
    # echo "Going to $2..."
    /usr/bin/echo "0" > /sys/class/vtconsole/vtcon1/bind
    /usr/bin/rmmod nouveau
    ;;
  post/*)
    # echo "Waking up from $2..."
    /usr/bin/modprobe nouveau
    /usr/bin/echo "1" > /sys/class/vtconsole/vtcon1/bind
    ;;
esac

1つ目の echo 行は、フレームバッファコンソールドライバ (fbcon) から nouveaufb をアンバインドします。通常、この例にあるように vtcon1 ですが、他の vtcon* である場合もあります。どれがフレームバッファデバイスであるかは /sys/class/vtconsole/vtcon*/name を確認してください [5]。

翻訳ステータス: このページは en:Power management/Wakeup triggers の翻訳バージョンです。最後の翻訳日は 2023-06-20 です。もし英語版に変更があれば、翻訳の同期を手伝うことができます。

@@ 1行目: / 1行目: @@
-[[Category:ハードウェア検出とトラブルシューティング]]
 [[Category:電源管理]]
 [[Category:ノートパソコン]]
-[[en:Wakeup triggers]]
+[[en:Power management/Wakeup triggers]]
+[[zh-hans:Power management/Wakeup triggers]]
 {{Related articles start}}
 {{Related|電源管理}}
-{{Related|サスペンドとハイバネート}}
 {{Related|Wake-on-LAN}}
-{{Related|udev}}
 {{Related|ノートパソコン}}
 {{Related articles end}}
-復帰トリガー(ウェイクアップトリガー)とは、ハードウェアの任意の[[電源管理|省電力]][[w:Advanced Configuration and Power Interface#Power states|状態]]からシステムを復帰させることのできるイベント要因です。自明な例としては、電源ボタンやスリープボタン、[[Wake-on-LAN]] 機能、[[ノートパソコン]]のリッドスイッチがあります。復帰トリガーは、以下に挙げる様々な[[カーネル]]インターフェイスにより制御できます。すべての可能なトリガーをカバーする統一されたインターフェイスは存在しません。
+復帰トリガー (ウェイクアップトリガー) とは、ハードウェアの任意の[[電源管理|省電力]][[w:Advanced Configuration and Power Interface#Power states|状態]]からシステムを復帰させることのできるイベント要因です。自明な例としては、電源ボタンやスリープボタン、[[Wake-on-LAN]] 機能、[[ノートパソコン]]の蓋のスイッチがあります。復帰トリガーは、以下に挙げる様々な[[カーネル]]インターフェイスにより制御できます。すべての可能なトリガーをカバーする統一されたインターフェイスは存在しません。
 == 復帰トリガーインターフェイス ==
@@ 17行目: / 15行目: @@
 === /proc/acpi/wakeup ===
+{{ic|/proc/acpi/wakeup}} ファイルを読み出すと、ACPI に登録されているウェイクアップ要因のリストが得られます。利用可能であれば、対応する {{ic|sysfs}} も得られます。''Device'' 列のエントリをそのファイルに書き込めば、状態を切り替えることができます。例えば、ラップトップを開いたときの復帰を無効化するには:
-Reading the {{ic|/proc/acpi/wakeup}} file yields list of ACPI-registered wakeup sources with corresponding {{ic|sysfs}} IDs where available. Writing an entry from the ''Device'' column to the file toggles its state. For example, to disable waking on opening the laptop lid, run:
  # echo "LID" > /proc/acpi/wakeup
@@ 23行目: / 21行目: @@
 === /sys/module/acpi/parameters/ec_no_wakeup ===
-This file represents the value of ACPI [[kernel module]] option {{ic|ec_no_wakeup}}, which controls passing the wakeup triggers from embedded controller when the system is in the suspend-to-idle ({{ic|s2idle}}) [[Power management/Suspend and hibernate|power state]] [https://docs.kernel.org/admin-guide/pm/sleep-states.html]. On modern laptops embedded controller wakeups can cause excessive battery drain in [[Lenovo ThinkPad Helix 2nd Gen#Disable embedded-controller wake-ups|some]] cases.
+このファイルは ACPI [[カーネルモジュール]]オプション {{ic|ec_no_wakeup}} の値を表しています。このオプションは、システムが suspend-to-idle ({{ic|s2idle}}) [[サスペンドとハイバネート|電源状態]]にあるときに組み込みコントローラからの復帰トリガーを渡すかどうかを制御します [https://docs.kernel.org/admin-guide/pm/sleep-states.html]。最近のノートパソコンでは、[[:en:Lenovo ThinkPad Helix 2nd Gen#Disable embedded-controller wake-ups|一部]]のケースで組み込みコントローラの復帰によりバッテリーの過剰な消耗を引き起こすことがあります。
 === /sys/devices/ ===
+復帰をサポートする {{ic|sysfs}} デバイスには、デバイスの {{ic|power}} サブディレクトリ内の {{ic|wakeup}} ファイルがそれぞれ含まれています。このファイルには、復帰トリガーの状態が含まれ、書き込むこともできます。バスコントローラとエンドポイントデバイスは、システムを復帰させることができる可能性があります。例えば、USB コントローラ (バス) からの復帰を無効化するには:
-Each {{ic|sysfs}} device that supports wakeup contains the file {{ic|wakeup}} in a device's {{ic|power}} subdirectory. The file contains wakeup trigger's status and can be written to as well. Bus controllers as well as endpoint devices can be capable of waking up the system. For example, to disable wakeups from the first USB controller (bus), run:
  # echo "disabled" > /sys/bus/usb/devices/usb1/power/wakeup
+コントローラの設定に関わらず、トリガーが有効化されていれば、エンドポイントデバイスはデバイスを復帰させることができるはずです。しかし、これはハードウェア依存である可能性があります。
-An endpoint device should be able to wake the device if the trigger is enabled regardless of the controller's setting, however this might be hardware-dependent.
+{{ic|sysfs}} で [[Powertop|PowerTOP]] インターフェイスをプログラムしてください。ただし、{{ic|/sys/class/net/}} と {{ic|/sys/bus/usb/devices/}} ({{ic|/sys/devices/}} へのシンボリックリンクを含みます) を読み出しても、ネットワーキングデバイスと USB デバイスの復帰トリガーしか得られません。
-Program [[Powertop|PowerTOP]] interfaces with {{ic|sysfs}}, but it only lists wakeup triggers of networking and USB devices by reading {{ic|/sys/class/net/}} and {{ic|/sys/bus/usb/devices/}} (containing symlinks to {{ic|/sys/devices/}}).
 === /sys/class/wakeup/* ===
+{{ic|/sys/class/wakeup}} ディレクトリにほぼすべての復帰トリガーがあります。このディレクトリには、関連するすべてのデバイスへのシンボリックリンクを含みます。サブディレクトリを見れば、利用可能な復帰トリガーを探すのに便利です。一部のトリガーは仮想デバイスに対応している可能性があります。一方、ハードウェア関連の復帰トリガーは、以下のファイルのうち少なくとも1つが含まれています:
-Almost all wakeup triggers can be found in the {{ic|/sys/class/wakeup}} directory, which contains symlinks to all relevant devices. This is useful for finding possible wakeup triggers by going through subdirectories. Some of the triggers can correspond to virtual devices while hardware-related wakeup triggers are the ones that contain at least one of these files:
  /sys/class/wakeup/*/device/physical_node/power/wakeup
  /sys/class/wakeup/*/device/power/wakeup
-Some of wakeup triggers in {{ic|/sys/class/wakeup}} also provide a link to the cryptic {{ic|/proc/acpi/wakeup}} names where the following file is present:
+{{ic|/sys/class/wakeup}} 内の復帰トリガーのいくつかは、以下のファイルが存在する暗号化された {{ic|/proc/acpi/wakeup}} 名へのリンクを提供します:
  /sys/class/wakeup/*/device/path
@@ 48行目: / 46行目: @@
 == 永続的な設定 ==
-The ''one-time'' methods should suffice for setting the {{ic|/proc/acpi/wakeup}} states and {{ic|acpi.ec_no_wakeups}} [[kernel parameter]] while the ''event-driven'' approach with [[udev]] is the reliable way to configure the {{ic|sysfs}} devices.
+''ワンタイム''な方法は、{{ic|/proc/acpi/wakeup}} の状態や {{ic|acpi.ec_no_wakeups}} [[カーネルパラメータ]]を設定するには十分なはずです。[[udev]] を用いる''イベント駆動''のアプローチは、{{ic|sysfs}} デバイスを設定する際に信頼性の高い方法です。
+=== systemd によるワンタイムな方法 ===
-=== One-time with systemd ===
-The {{ic|ec_no_wakeups}} ACPI [[kernel module]] option can be set at boot as described in the article. The standard solution to set the {{ic|sysfs}} values at boot are [[systemd#Writing unit files|systemd services]] such as in this troubleshooting [[Power management#PC will not wake from sleep on A520I and B550I motherboards|case]]. Another [[systemd]]-based manager for {{ic|/proc/acpi/wakeup}} is {{AUR|wakeup-triggers}}.
+{{ic|ec_no_wakeups}} ACPI [[カーネルモジュール]]オプションは、この記事で説明されているように起動時に設定できます。{{ic|sysfs}} の値を起動時に設定する標準的な方法は [[systemd#ユニットファイル|systemd サービス]]です (例えばこのトラブルシューティングの[[:en:Power management#PC will not wake from sleep on A520I and B550I motherboards|場合]]のように)。他にも、{{ic|/proc/acpi/wakeup}} 用の [[systemd]] ベースのマネージャとして {{AUR|wakeup-triggers}} があります。
+一部のシステムは、電源状態の遷移時にいくつかの ACPI 復帰トリガーを上書きする可能性があります (これは機能というよりバグです)。ハードウェアがトリガーを上書きするタイミングが予測可能な場合、適切な [[systemd#ユニットファイル|systemd ユニット]]によりこの問題を解決することができます。{{ic|sleep.target}} は、すべてのサスペンド状態をカバーする汎用 target で、この問題を解決するのに役立つかもしれません。しかし、汎用の {{ic|wakeup.target}} は存在しません [https://github.com/systemd/systemd/issues/6364]。
-Some systems can override some of the ACPI wakeup triggers upon power state transition(s) in what is more of a bug rather than a feature. If the hardware is overriding triggers at predictable times that can still be solved with appropriately crafted [[systemd#Writing unit files|systemd units]]. The {{ic|sleep.target}} is a generic target covering all different suspended states that might be helpful in this case, but there is no generic {{ic|wakeup.target}} [https://github.com/systemd/systemd/issues/6364].
+この方法は、常に接続されている {{ic|sysfs}} デバイスに対してのみ、確実に動作します。
-This method only works reliably with {{ic|sysfs}} devices that are connected all the time.
+=== udev によるイベント駆動の方法 ===
-=== Event-driven with udev ===
+[[udev]] ルールによる復帰トリガーの状態設定は、復帰トリガーを持つデバイスが接続されている時であれば常に動作するイベント駆動の方法です。重要なのは、ルールで新しいデバイスの追加を検出し ({{ic|1=ACTION=="add"}})、{{ic|1=ATTR{power/wakeup}="disabled"}} で復帰トリガーの状態を設定することです。この設定をハードウェアがリセットしてしまう場合、udev はデバイスの変更のたびにルールを再適用してこの問題の回避を試みることができます ({{ic|1=ACTION=="add{{!}}change"}})。{{ic|sysfs}} で見つかった特定のデバイスにマッチする利用可能なパラメータとデバイスツリーは、{{ic|udevadm info -q all -a /sys/devices/...}} を使って得られます。
-Setting the wakeup trigger status with [[udev]] rules is an event-driven method that works reliably any time the devices with wakeup triggers are connected. The key is to detect an addition of a new device ({{ic|1=ACTION=="add"}}) in a rule and set the wakeup trigger status with {{ic|1=ATTR{power/wakeup}="disabled"}}. If the hardware is resetting this setting, udev can try to circumvent it by reapplying rules upon every device change ({{ic|1=ACTION=="add{{!}}change"}}). A device tree with possible parameters for matching a particular device found in {{ic|sysfs}} can be obtained with {{ic|udevadm info -q all -a /sys/devices/...}}.
+一般的な例としては、Logitech Unifying USB があります。このデバイスの復帰トリガーはデフォルトで有効になっているはずです。これが気に入らない場合、[[udev]] ルールで解決できるかもしれません:
-A representative common example here would be a Logitech Unifying USB receiver. Its wakeup trigger should be enabled by default and if that is not desired, a solution could be an [[udev]] rule, as follows:
 {{hc|/etc/udev/rules.d/logitech-unifying.rules|2=
@@ 68行目: / 66行目: @@
 }}
+逆に、必要なトリガーを有効化する場合については [[Udev#USB デバイスでサスペンドから復帰させる|udev]] の記事で説明されています。
-The reverse case to enable the necessary trigger(s) is described in the [[Udev#Waking from suspend with USB device|udev]] article.
+udev はデバイス列挙の初期にトリガーするので、復帰トリガーを上記の方法で無効化すると、無効化したトリガー (の一部?) が {{ic|/sys/class/wakeup}} にリストされません。これは、起動時にデバイスが存在していたかどうかに依存しているかもしれませんが、さらなる解明が必要です。
-udev triggers so early in the device enumeration that disabling wakeup trigger with the method above causes (some?) disabled triggers to not be listed in {{ic|/sys/class/wakeup}}. That might be dependent on whether the device was already present at boot and needs further clarification.
 == トラブルシューティング ==
@@ 84行目: / 82行目: @@
 === サスペンドからすぐに復帰する ===
-LynxPoint や LynxPoint-LP チップセットが搭載された Intel Haswell の場合、サスペンドからすぐに復帰してしまうと報告されています。BIOS の ACPI 実装に問題があり起動時に {{ic|xhci_hcd}} モジュールによって ACPI イベントが解釈されてしまうのが原因です。解決策としてカーネルによってケースバイケースで問題のあるシステムがブラックリスト ({{ic|XHCI_SPURIOUS_WAKEUP}}) に追加されています [https://bugzilla.kernel.org/show_bug.cgi?id=66171#c6]。
+LynxPoint や LynxPoint-LP チップセットが搭載された一部の Intel Haswell システムにおいて、サスペンドからすぐに復帰してしまうと報告されています。これは、BIOS の問題のある ACPI 実装と、起動時に {{ic|xhci_hcd}} モジュールが ACPI イベントを解釈する方法に関連しています。解決策として、影響を受けるシステムは ({{ic|XHCI_SPURIOUS_WAKEUP}} という名前の) ブラックリストにケースバイケースで追加されています [https://bugzilla.kernel.org/show_bug.cgi?id=66171#c6]。
-サスペンド中に USB デバイスを接続したときなどに ACPI の復帰トリガーが有効になって復帰してしまいます。ブラックリストに追加されるまで一時的な応急処置としては復帰トリガーを無効化する方法があります。以下の設定で USB による復帰を無効化することができます [https://bbs.archlinux.org/viewtopic.php?pid=1575617]。
+サスペンド中に USB デバイスを接続したときなどに ACPI の復帰トリガーが有効になって、即座に復帰してしまうことがあります。ブラックリストに追加されるまで一時的な応急処置としては復帰トリガーを無効化する方法があります。以下の設定で USB による復帰を無効化することができます [https://bbs.archlinux.org/viewtopic.php?pid=1575617]。
-現在の設定を確認:
+現在の設定を確認するには:
 {{hc|$ cat /proc/acpi/wakeup|
@@ 99行目: / 97行目: @@
 }}
-問題のデバイスは {{ic|EHC1}}, {{ic|EHC1}}, {{ic|XHC}} (USB 3.0) です。状態を変更するには root でデバイス名をファイルに echo してください:
+問題のデバイスは {{ic|EHC1}}、{{ic|EHC1}}、{{ic|XHC}} (USB 3.0) です。状態を変更するには root としてデバイス名をファイルに echo してください:
  # echo EHC1 > /proc/acpi/wakeup
@@ 105行目: / 103行目: @@
  # echo XHC > /proc/acpi/wakeup
-上記のコマンドでサスペンドが再度機能するようになります。ただし、設定は一時的なものなので再起動するたびに設定し直す必要があります。自動化したい場合は [[systemd#ユニットファイル]]を見てください。詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617 BBS スレッド] を参照。
+上記のコマンドでサスペンドが再度機能するようになるはずです。ただし、設定は一時的なものなので起動するたびに設定し直す必要があります。自動化したい場合は [[systemd-tmpfiles]] を見てください。この問題に対する利用可能な解決策は [https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617 BBS スレッド] を見てください。
+B550i Aorus や B550 AORUS ELITE V2 などの Gigabyte のマザーボードでは、NVMe ドライブへの GPP ブリッジがサスペンドからすぐに復帰する原因になる場合があります。{{ic|GPP0}} の状態を ''disabled'' に設定することでこの問題を解決できる場合があります:
+ # echo GPP0 > /proc/acpi/wakeup
+==== NVIDIA ドライバ ====
+[[NVIDIA]] のプロプライエタリドライバをインストールすると、サスペンドとハイバネートができなくなることがあります。そのようなケースでは、システムログに以下のメッセージが残ることがあります:
+ kernel: NVRM: GPU 0000:01:00.0: PreserveVideoMemoryAllocations module parameter is set. System Power Management attempted without driver procfs suspend interface. Please refer to the 'Configuring Power Management Support' section in the driver README.
+ kernel: PM: pci_pm_suspend(): nv_pmops_suspend+0x0/0x20 [nvidia] returns -5
+ kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -5
+ kernel: nvidia 0000:01:00.0: PM: failed to suspend async: error -5
+[[NVIDIA/ヒントとテクニック#サスペンド後にビデオメモリを保持する]] を参照してください。
 ==== nouveau ドライバ ====
-[[nouveau]] ドライバを使用している場合、サスペンドから即座に復帰してしまう原因はドライバのバグかもしれません(時々 GPU のサスペンドを妨げてしまいます)。回避策は、スリープする直前に {{ic|nouveau}} カーネルモジュールをアンロードして、復帰した時に再びロードすることです。これを行うには、以下のスクリプトを作成してください:
+[[nouveau]] ドライバを使用している場合、サスペンドから即座に復帰してしまう原因はドライバのバグかもしれません (nouveau ドライバは GPU のサスペンドを妨げてしまうことがあります)。回避策は、スリープする直前に {{ic|nouveau}} カーネルモジュールをアンロードして、復帰した時に再びロードすることです。これを行うには、以下のスクリプトを作成してください:
 {{hc|/usr/lib/systemd/system-sleep/10-nouveau.sh|2=
@@ 128行目: / 141行目: @@
 }}
-つ目の echo 行は、フレームバッファコンソールドライバ({{ic|fbcon}})から {{ic|nouveaufb}} をアンバインドします。通常、この例にあるように {{ic|vtcon1}} ですが、他の {{ic|vtcon*}} である場合もあります。どれが''フレームバッファデバイス''であるかは {{ic|/sys/class/vtconsole/vtcon*/name}} を確認してください[https://nouveau.freedesktop.org/wiki/KernelModeSetting/]。
+つ目の echo 行は、フレームバッファコンソールドライバ ({{ic|fbcon}}) から {{ic|nouveaufb}} をアンバインドします。通常、この例にあるように {{ic|vtcon1}} ですが、他の {{ic|vtcon*}} である場合もあります。どれが''フレームバッファデバイス''であるかは {{ic|/sys/class/vtconsole/vtcon*/name}} を確認してください [https://nouveau.freedesktop.org/wiki/KernelModeSetting/]。
+{{TranslationStatus|Power management/Wakeup triggers|2023-06-20|781520}}