「電源管理/復帰トリガー」の版間の差分
(→永続的な設定: 翻訳) |
|||
| 48行目: | 48行目: | ||
== 永続的な設定 == |
== 永続的な設定 == |
||
| − | + | ''ワンタイム''な方法は、{{ic|/proc/acpi/wakeup}} の状態や {{ic|acpi.ec_no_wakeups}} [[カーネルパラメータ]]を設定するには十分なはずです。[[udev]] を用いる''イベント駆動''のアプローチは、{{ic|sysfs}} デバイスを設定する信頼性の高い方法です。 |
|
| + | === systemd によるワンタイムな方法 === |
||
| − | === One-time with 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}} があります。 |
|
| + | 一部のシステムは、電源状態の遷移時にいくつかの 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= |
{{hc|/etc/udev/rules.d/logitech-unifying.rules|2= |
||
| 68行目: | 68行目: | ||
}} |
}} |
||
| + | 逆に、必要なトリガーを有効化する場合については [[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. |
||
== トラブルシューティング == |
== トラブルシューティング == |
||
2022年7月24日 (日) 10:20時点における版
復帰トリガー(ウェイクアップトリガー)とは、ハードウェアの任意の省電力状態からシステムを復帰させることのできるイベント要因です。自明な例としては、電源ボタンやスリープボタン、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
コントローラの設定に関わらず、トリガーが有効化されていれば、エンドポイントデバイスはデバイスを復帰させることができるはずです。しかし、これはハードウェア依存である可能性があります。
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-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 ...
問題のデバイスは EHC1, EHC1, XHC (USB 3.0) です。状態を変更するには root でデバイス名をファイルに echo してください:
# echo EHC1 > /proc/acpi/wakeup # echo EHC2 > /proc/acpi/wakeup # echo XHC > /proc/acpi/wakeup
上記のコマンドでサスペンドが再度機能するようになります。ただし、設定は一時的なものなので再起動するたびに設定し直す必要があります。自動化したい場合は systemd#ユニットファイルを見てください。詳しくは BBS スレッド を参照。
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]。