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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(リンクを修正)
 
(同じ利用者による、間の5版が非表示)
1行目: 1行目:
[[Category:ハードウェア検出とトラブルシューティング]]
 
 
[[Category:電源管理]]
 
[[Category:電源管理]]
 
[[Category:ノートパソコン]]
 
[[Category:ノートパソコン]]
[[en:Wakeup triggers]]
+
[[en:Power management/Wakeup triggers]]
  +
[[zh-hans:Power management/Wakeup triggers]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|電源管理}}
 
{{Related|電源管理}}
{{Related|サスペンドとハイバネート}}
 
 
{{Related|Wake-on-LAN}}
 
{{Related|Wake-on-LAN}}
{{Related|udev}}
 
 
{{Related|ノートパソコン}}
 
{{Related|ノートパソコン}}
 
{{Related articles end}}
 
{{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]] 機能、[[ノートパソコン]]の蓋のスイッチがあります。復帰トリガーは、以下に挙げる様々な[[カーネル]]インターフェイスにより制御できます。すべての可能なトリガーをカバーする統一されたインターフェイスは存在しません。
   
 
== 復帰トリガーインターフェイス ==
 
== 復帰トリガーインターフェイス ==
23行目: 21行目:
 
=== /sys/module/acpi/parameters/ec_no_wakeup ===
 
=== /sys/module/acpi/parameters/ec_no_wakeup ===
   
このファイルは 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|一部]]のケースで組み込みコントローラの復帰によりバッテリーの過剰な消耗を引き起こすことがあります。
+
このファイルは 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/ ===
 
=== /sys/devices/ ===
   
復帰をサポートする {{ic|sysfs}} デバイスには、デバイスの {{ic|power}} サブディレクトリ内の {{ic|wakeup}} ファイルがそれぞれ含まれています。このファイルには、復帰トリガーの状態が含まれ、書き込むこともできます。バスコントローラとエンドポイントデバイスは、システムを復帰させることができる可能性があります。例えば、USB コントローラ(バス)からの復帰を無効化するには:
+
復帰をサポートする {{ic|sysfs}} デバイスには、デバイスの {{ic|power}} サブディレクトリ内の {{ic|wakeup}} ファイルがそれぞれ含まれています。このファイルには、復帰トリガーの状態が含まれ、書き込むこともできます。バスコントローラとエンドポイントデバイスは、システムを復帰させることができる可能性があります。例えば、USB コントローラ (バス) からの復帰を無効化するには:
   
 
# echo "disabled" > /sys/bus/usb/devices/usb1/power/wakeup
 
# echo "disabled" > /sys/bus/usb/devices/usb1/power/wakeup
33行目: 31行目:
 
コントローラの設定に関わらず、トリガーが有効化されていれば、エンドポイントデバイスはデバイスを復帰させることができるはずです。しかし、これはハードウェア依存である可能性があります。
 
コントローラの設定に関わらず、トリガーが有効化されていれば、エンドポイントデバイスはデバイスを復帰させることができるはずです。しかし、これはハードウェア依存である可能性があります。
   
{{ic|sysfs}} で [[Powertop|PowerTOP]] インターフェイスをプログラムしてください。ただし、{{ic|/sys/class/net/}} と {{ic|/sys/bus/usb/devices/}} ({{ic|/sys/devices/}} へのシンボリックリンクを含みます)を読み出しても、ネットワーキングデバイスと USB デバイスの復帰トリガーしか得られません。
+
{{ic|sysfs}} で [[Powertop|PowerTOP]] インターフェイスをプログラムしてください。ただし、{{ic|/sys/class/net/}} と {{ic|/sys/bus/usb/devices/}} ({{ic|/sys/devices/}} へのシンボリックリンクを含みます) を読み出しても、ネットワーキングデバイスと USB デバイスの復帰トリガーしか得られません。
   
 
=== /sys/class/wakeup/* ===
 
=== /sys/class/wakeup/* ===
   
{{ic|/sys/class/wakeup}} ディレクトリにほぼすべての復帰トリガーがあります。このディレクトリは、関連するすべてのデバイスへのシンボリックリンクを含みます。サブディレクトリを見れば、可能な復帰トリガーを探すのに便利です。一部のトリガーは仮想デバイスに対応している可能性があります。一方、ハードウェア関連の復帰トリガーは、以下のファイルのうち少なくとも1つが含まれています:
+
{{ic|/sys/class/wakeup}} ディレクトリにほぼすべての復帰トリガーがあります。このディレクトリは、関連するすべてのデバイスへのシンボリックリンクを含みます。サブディレクトリを見れば、利用可能な復帰トリガーを探すのに便利です。一部のトリガーは仮想デバイスに対応している可能性があります。一方、ハードウェア関連の復帰トリガーは、以下のファイルのうち少なくとも1つが含まれています:
   
 
/sys/class/wakeup/*/device/physical_node/power/wakeup
 
/sys/class/wakeup/*/device/physical_node/power/wakeup
 
/sys/class/wakeup/*/device/power/wakeup
 
/sys/class/wakeup/*/device/power/wakeup
   
{{ic|/sys/class/wakeup}} 内の復帰トリガーのいくつかは、以下のファイルが存在する暗号化された {{ic|/proc/acpi/wakeup}} 名へのリンクを提供します:
+
{{ic|/sys/class/wakeup}} 内の復帰トリガーのいくつかは、以下のファイルが存在する暗号化された {{ic|/proc/acpi/wakeup}} 名へのリンクを提供します:
   
 
/sys/class/wakeup/*/device/path
 
/sys/class/wakeup/*/device/path
48行目: 46行目:
 
== 永続的な設定 ==
 
== 永続的な設定 ==
   
''ワンタイム''な方法は、{{ic|/proc/acpi/wakeup}} の状態や {{ic|acpi.ec_no_wakeups}} [[カーネルパラメータ]]を設定するには十分なはずです。[[udev]] を用いる''イベント駆動''のアプローチは、{{ic|sysfs}} デバイスを設定する信頼性の高い方法です。
+
''ワンタイム''な方法は、{{ic|/proc/acpi/wakeup}} の状態や {{ic|acpi.ec_no_wakeups}} [[カーネルパラメータ]]を設定するには十分なはずです。[[udev]] を用いる''イベント駆動''のアプローチは、{{ic|sysfs}} デバイスを設定する際に信頼性の高い方法です。
   
 
=== systemd によるワンタイムな方法 ===
 
=== systemd によるワンタイムな方法 ===
   
{{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}} があります。
+
{{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]。
+
一部のシステムは、電源状態の遷移時にいくつかの ACPI 復帰トリガーを上書きする可能性があります (これは機能というよりバグです)。ハードウェアがトリガーを上書きするタイミングが予測可能な場合、適切な [[systemd#ユニットファイル|systemd ユニット]]によりこの問題を解決することができます。{{ic|sleep.target}} は、すべてのサスペンド状態をカバーする汎用 target で、この問題を解決するのに役立つかもしれません。しかし、汎用の {{ic|wakeup.target}} は存在しません [https://github.com/systemd/systemd/issues/6364]。
   
 
この方法は、常に接続されている {{ic|sysfs}} デバイスに対してのみ、確実に動作します。
 
この方法は、常に接続されている {{ic|sysfs}} デバイスに対してのみ、確実に動作します。
60行目: 58行目:
 
=== udev によるイベント駆動の方法 ===
 
=== 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/...}} を使って得られます。
+
[[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/...}} を使って得られます。
   
 
一般的な例としては、Logitech Unifying USB があります。このデバイスの復帰トリガーはデフォルトで有効になっているはずです。これが気に入らない場合、[[udev]] ルールで解決できるかもしれません:
 
一般的な例としては、Logitech Unifying USB があります。このデバイスの復帰トリガーはデフォルトで有効になっているはずです。これが気に入らない場合、[[udev]] ルールで解決できるかもしれません:
68行目: 66行目:
 
}}
 
}}
   
逆に、必要なトリガーを有効化する場合については [[Udev#USB デバイスでサスペンドから復帰|udev]] の記事で説明されています。
+
逆に、必要なトリガーを有効化する場合については [[Udev#USB デバイスでサスペンドから復帰させる|udev]] の記事で説明されています。
   
udev はデバイス列挙の初期にトリガーするので、復帰トリガーを上記の方法で無効化すると、無効化したトリガー(の一部?)が {{ic|/sys/class/wakeup}} にリストされません。これは、起動時にデバイスが存在していたかどうかに依存しているかもしれませんが、さらなる解明が必要です。
+
udev はデバイス列挙の初期にトリガーするので、復帰トリガーを上記の方法で無効化すると、無効化したトリガー (の一部?) が {{ic|/sys/class/wakeup}} にリストされません。これは、起動時にデバイスが存在していたかどうかに依存しているかもしれませんが、さらなる解明が必要です。
   
 
== トラブルシューティング ==
 
== トラブルシューティング ==
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|
 
{{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
 
# echo EHC1 > /proc/acpi/wakeup
105行目: 103行目:
 
# echo XHC > /proc/acpi/wakeup
 
# 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 ドライバ ====
   
[[nouveau]] ドライバを使用している場合、サスペンドから即座に復帰してしまう原因はドライバのバグかもしれません(時々 GPU のサスペンドを妨げてしまます)。回避策は、スリープする直前に {{ic|nouveau}} カーネルモジュールをアンロードして、復帰した時に再びロードすることです。これを行うには、以下のスクリプトを作成してください:
+
[[nouveau]] ドライバを使用している場合、サスペンドから即座に復帰してしまう原因はドライバのバグかもしれません (nouveau ドライバは GPU のサスペンドを妨げてしまうことがあります)。回避策は、スリープする直前に {{ic|nouveau}} カーネルモジュールをアンロードして、復帰した時に再びロードすることです。これを行うには、以下のスクリプトを作成してください:
   
 
{{hc|/usr/lib/systemd/system-sleep/10-nouveau.sh|2=
 
{{hc|/usr/lib/systemd/system-sleep/10-nouveau.sh|2=
128行目: 141行目:
 
}}
 
}}
   
1つ目の echo 行は、フレームバッファコンソールドライバ({{ic|fbcon}})から {{ic|nouveaufb}} をアンバインドします。通常、この例にあるように {{ic|vtcon1}} ですが、他の {{ic|vtcon*}} である場合もあります。どれが''フレームバッファデバイス''であるかは {{ic|/sys/class/vtconsole/vtcon*/name}} を確認してください[https://nouveau.freedesktop.org/wiki/KernelModeSetting/]。
+
1つ目の echo 行は、フレームバッファコンソールドライバ ({{ic|fbcon}}) から {{ic|nouveaufb}} をアンバインドします。通常、この例にあるように {{ic|vtcon1}} ですが、他の {{ic|vtcon*}} である場合もあります。どれが''フレームバッファデバイス''であるかは {{ic|/sys/class/vtconsole/vtcon*/name}} を確認してください [https://nouveau.freedesktop.org/wiki/KernelModeSetting/]。
   
{{TranslationStatus|Wakeup triggers|2022-07-22|738730}}
+
{{TranslationStatus|Power management/Wakeup triggers|2023-06-20|781520}}

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

関連記事

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

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

/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

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

sysfsPowerTOP インターフェイスをプログラムしてください。ただし、/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-triggersAUR があります。

一部のシステムは、電源状態の遷移時にいくつかの 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
...

問題のデバイスは EHC1EHC1XHC (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 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。