「電源管理/サスペンドとハイバネート」の版間の差分

2016年10月25日 (火) 08:45時点における版

現在サスペンドには3つの手法が存在します: suspend to RAM (通常はサスペンドとだけ呼ばれます)、suspend to disk (通常はハイバネートと呼ばれます)、そして hybrid suspend (suspend to both とも呼ばれます):

Suspend to RAM は RAM を除くマシンのほとんど全てのパーツの電源を切ります。RAM への電源はマシンの状態を保存するために必要です。電力を多く節約できるので、ラップトップでは、バッテリーでコンピュータが稼働していてフタが閉じられた時 (もしくはユーザーが長い間操作しなかった時) は自動的にこのモードに移行するのが得策でしょう。

Suspend to disk はマシンの状態をスワップ領域に保存してマシンの電源を完全にオフにします。マシンに電源を入れた時、状態が復元されます。それまでは、電力消費量はゼロです。

Suspend to both はマシンの状態をスワップ領域に保存しますが、マシンの電源を切りません。代わりに、通常の suspend to RAM を呼び出します。これによって、バッテリーを使いきっても、システムを RAM から復帰することが可能です。バッテリーが枯渇した時は、システムはディスクから復帰し、RAM からの復帰に比べて時間がかかりますが、システムの状態が失われることはありません。

基本的な機能を提供する低レベルなインターフェイス (バックエンド) が複数存在し、問題のあるハードウェアドライバ・カーネルモジュール (例: ビデオカードの再初期化) を扱う機能を提供する高レベルなインターフェイスもいくつかあります。

低レベルインターフェイス

これらのインターフェイスは直接使うこともできますが、通常は高レベルインターフェイスを使ってサスペンド・ハイバネートを行うとよいでしょう。低レベルなインターフェイスを直接使うと、サスペンドの前や後に行うフック処理を全て実行する高レベルインターフェイスよりもかなり早くサスペンドが可能です。ただしフックはハードウェアクロックの設定や、ワイヤレスの復旧などを正しく処理することができます。

カーネル (swsusp)

直球の方法はカーネル内のソフトウェアサスペンドコード (swsusp) にサスペンド状態に入るよう直接伝えることです。実際の方法と状態はハードウェアサポートのレベルによります。最近のカーネルでは、サスペンドにするために /sys/power/state に適切な文字列を書くことが主な方法になっています。

詳しくはカーネルドキュメントを参照してください。

uswsusp

uswsusp ('Userspace Software Suspend') はカーネルの suspend-to-RAM のラッパーで、サスペンドの前と復帰の後にユーザー空間からグラフィックアダプタの操作を行います。

Uswsusp の記事を参照してください。

tuxonice

TuxOnIce はサスペンド・ハイバネートのカーネル実装のフォークで、デフォルトの実装を改善するカーネルパッチを提供しています。これを使うためにはカスタムカーネルが必要です。

TuxOnIce の記事を参照してください。

高レベルインターフェイス

ノート: これらのパッケージではサスペンド・ハイバネートを行うためのバイナリ・スクリプトを提供します。実際に電源ボタンやメニュークリック、ラップトップのカバーのイベントなどと結びつけるのは他のツールで行うのが通常です。（ラップトップのカバーが閉じられたり、バッテリーが枯渇するなど）特定の電源イベントで自動的にサスペンド・ハイバネートをするには、Acpid の実行について調べて下さい。

systemd

systemd はサスペンド・ハイバネート・ハイブリッドサスペンドを行うためのネイティブのコマンドを提供しています。詳しくは電源管理#systemd による電源管理を見て下さい。これは Arch Linux で使われているデフォルトのインターフェースです。

サスペンド・ハイバネートのフックの設定に関する情報は電源管理#スリープフックに載っています。man systemctl, man systemd-sleep, man systemd.special もあわせて参照してください。

pm-utils

pm-utils はバックエンドのサスペンド・ハイバネート機能をカプセル化するシェルスクリプトのセットです。サスペンドの前後に行う設定やプロセスをカスタマイズするための様々なフックも入っています。

pm-utils の記事を参照してください。

ハイバネーション

ハイバネーションを使うには、スワップパーティションかスワップファイルを作成する必要があります。そして resume= カーネルパラメータを使ってスワップを指定してください。カーネルパラメータはブートローダで設定します。initramfs の設定も必要になります。設定によってカーネルは初期ユーザー空間で指定されたスワップからの復帰を試みます。以下ではスワップの作成・カーネルパラメータの設定・initramfs の設定について詳細に説明します。

スワップパーティション（ファイル）のサイズについて

スワップパーティションが RAM より小さかったとしても、ハイバネートが成功する可能性は高いと思われます。カーネルドキュメントによると:

/sys/power/image_size は suspend-to-disk によって作成されるイメージのサイズを制御します。イメージサイズの上限として使われる負ではない整数 (バイト) を示す文字列で書くことが出来ます。suspend-to-disk はイメージサイズがその数字を超えないように出来る限りのことをします。ただし、それが無理だということがわかったら、とにかく出来る限り小さいイメージを使ってサスペンドを試みます。特に、このファイルに "0" と書かれていた場合、サスペンドのイメージは目一杯小さくなります。このファイルを読むと現在のイメージのサイズ制限が表示され、デフォルトでは利用可能な RAM の2/5に設定されています。

(スワップパーティションを小さくして) /sys/power/image_size の値を減らしてサスペンドのイメージを出来る限り小さくすることも、値を増やしてハイバネーションを高速化することも可能です。

必要なカーネルパラメータ

カーネルパラメータ resume=swap_partition を使う必要があります。swap_partition にはカーネルが割り当てたスワップパーティションの名前か、スワップパーティションの UUID を使うことができます。例:

resume=/dev/sda1
resume=UUID=4209c845-f495-4c43-8a03-5363dd433153
resume=/dev/mapper/archVolumeGroup-archLogicVolume -- LVM を使う場合の例

resume パラメータで使用する命名法は基本的に root パラメータで使用する命名法と同じにしてください。

設定は使用しているブートローダーによって異なります。詳しくはカーネルパラメータを参照してください。

スワップファイルにハイバネーション

警告: Btrfs はスワップファイルをサポートしていません。この警告に従わない場合、ファイルシステムが破損するおそれがあります。ループデバイスを経由してマウントしているときに Btrfs でスワップファイルを使うと、スワップパフォーマンスが著しく低下してしまいます。

スワップパーティションの代わりにスワップファイルを使うには追加のカーネルパラメータ resume_offset=swap_file_offset が必要です。

swap_file_offset の値は filefrag -v swap_file を実行することで取得できます。テーブル形式で出力され、必要な値は physical_offset カラムの一番上の段にあります。例えば:

# filefrag -v /swapfile

Filesystem type is: ef53
File size of /swapfile is 4294967296 (1048576 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:      38912..     38912:      1:            
   1:        1..   22527:      38913..     61439:  22527:             unwritten
   2:    22528..   53247:     899072..    929791:  30720:      61440: unwritten
...

この例では swap_file_offset の値は2つのピリオドが付いている最初の 38912 です。

swap_file_offset の値は swap-offset swap_file でも取得することができます。swap-offset バイナリは uswsusp-git^AUR パッケージに含まれています。

ノート:

カーネルパラメータ resume にはスワップファイル自体ではなく、スワップファイルが含まれているパーティションのデバイスを指定する必要があることに注意してください。カーネルパラメータ resume_offset は resume デバイス上に存在するスワップファイルの開始位置を示しています。カーネルパラメータを有効化するために、ハイバネーションをする前に再起動が必要です。
uswsusp を使う場合、resume device キーと resume offset キーを使って /etc/suspend.conf に上記2つのパラメータを記述してください。この場合再起動は必要ありません。

ヒント: スワップファイルを作成する目的が、仮想メモリの拡張ではなくハイバネートがしたいだけの場合、スワップファイルの Swappiness を減らすとよいでしょう。

initramfs の設定

initramfs で base フックを使っている場合 (Arch ではデフォルトで使っています)、/etc/mkinitcpio.conf に resume フックを追加する必要があります。ラベルあるいは UUID どちらを使用している場合でもスワップパーティションは udev デバイスノードによって参照されるので、resume フックは必ず udev の後に追加してください。デフォルトのフック設定に resume フックを追加すると以下のようになります:

HOOKS="base udev resume autodetect modconf block filesystems keyboard fsck"

変更を適用するために initramfs の再生成を忘れずに行ってください。

ノート: [LVM] を使っている場合は resume フックを lvm2 の後に追加してください。

initramfs で systemd フックを使っている場合は、復帰機構が既に提供されているので、フックを追加する必要はありません。

トラブルシューティング

ACPI_OS_NAME

DSDT table を動作するように設定することができます。DSDT の記事を参照してください。

VAIO ユーザー

acpi_sleep=nonvs カーネルフラグをブートローダに追加してください、これで OK です!

サスペンド/ハイバネートが動作しない、あるいはたまに動作しなくなる

サスペンドやハイバネートをした場合、あるいは復帰した場合に画面が表示されなくなるという報告が多数存在します。ノートパソコンとデスクトップの両方で問題は確認されています。正式な解決方法ではありませんが、古いカーネル、特に LTS カーネルに切り替えることで問題は解決することがあります。

initramfs からのデバイスの初期化によって画面が表示されなくなっていることもあります。Mkinitcpio#MODULES に追加したモジュールを削除して initramfs を再生成することで問題が解決するかもしれません。特にグラフィックドライバのモジュールは問題を起こしがちです。復帰するまえにデバイスが初期化されると矛盾状態になってシステムがハイバネートから復帰できなくなります。サスペンドからの復帰の場合は関係ありません。サスペンドやハイバネートの問題をデバッグする際のベストプラクティスがこちらの記事に記載されています。

Wake-on-LAN

Wake-on-LAN が有効になっている場合、コンピュータがハイバネート状態になっていてもネットワークインターフェイスカードによって電力が消費されます。

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

LynxPoint や LynxPoint-LP チップセットが搭載された Intel Haswell の場合、サスペンドからすぐに復帰してしまうと報告されています。BIOS の ACPI 実装に問題があり起動時に xhci_hcd モジュールによって ACPI イベントが解釈されてしまうのが原因です。解決策としてカーネルによってケースバイケースで問題のあるシステムがブラックリスト (XHCI_SPURIOUS_WAKEUP) に追加されています [1]。

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

現在の設定を確認:

$ 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#カスタム .service ファイルを書くを見てください。詳しくは BBS スレッドを参照。

@@ 59行目: / 59行目: @@
 == ハイバネーション ==
-ハイバネーションを使うには、[[スワップ]]パーティションかファイルを作成する必要があります。{{ic|1=resume=}} カーネルパラメータを使ってスワップを指定する必要がなります。これはブートローダを通して設定されます。[[#initramfs の設定|initramfs]] も必要になります。これによりカーネルは初期ユーザー空間の指定したスワップからの復帰を試みます。これら3つのステップは以下で詳細に述べます。
+ハイバネーションを使うには、[[スワップ]]パーティションかスワップファイルを作成する必要があります。そして {{ic|1=resume=}} カーネルパラメータを使ってスワップを指定してください。カーネルパラメータはブートローダで設定します。[[#initramfs の設定|initramfs の設定]]も必要になります。設定によってカーネルは初期ユーザー空間で指定されたスワップからの復帰を試みます。以下ではスワップの作成・カーネルパラメータの設定・initramfs の設定について詳細に説明します。
 === スワップパーティション（ファイル）のサイズについて ===
@@ 71行目: / 71行目: @@
 === 必要なカーネルパラメータ ===
-カーネルパラメータ {{ic|1=resume=''swap_partition''}} を使う必要があります。{{ic|''swap_partition''}} にはスワップパーティションのカーネル名か、スワップパーティションの [[UUID]] を使うことができます。例:
+カーネルパラメータ {{ic|1=resume=''swap_partition''}} を使う必要があります。{{ic|''swap_partition''}} にはカーネルが割り当てたスワップパーティションの名前か、スワップパーティションの [[UUID]] を使うことができます。例:
 * {{ic|1=resume=/dev/sda1}}
@@ 77行目: / 77行目: @@
 * {{ic|1=resume=/dev/mapper/archVolumeGroup-archLogicVolume}} -- LVM を使う場合の例
-{{ic|resume}} パラメータで使われる命名法は通常 {{ic|root}} パラメータで使われるものと同じにしてください。
+{{ic|resume}} パラメータで使用する命名法は基本的に {{ic|root}} パラメータで使用する命名法と同じにしてください。
 設定は使用している[[ブートローダー]]によって異なります。詳しくは[[カーネルパラメータ]]を参照してください。
@@ 98行目: / 98行目: @@
 </nowiki>}}
-この例では {{ic|''swap_file_offset''}} の値は 2つのピリオドが付いている 最初の {{ic|38912}} です。
+この例では {{ic|''swap_file_offset''}} の値は2つのピリオドが付いている最初の {{ic|38912}} です。
 {{ic|''swap_file_offset''}} の値は {{ic|swap-offset ''swap_file''}} でも取得することができます。''swap-offset'' バイナリは {{AUR|uswsusp-git}} パッケージに含まれています。
 {{Note|
-* カーネルパラメータ {{ic|resume}} にはスワップファイル自体ではなく、スワップファイルが含まれているパーティションのデバイスを記入する必要があることに注意してください。パラメータ {{ic|resume_offset}} は resume デバイスのどこからスワップファイルがあるかを示しています。これらを有効化するためには、最初のハイバネーションの前に再起動が必要です。
+* カーネルパラメータ {{ic|resume}} にはスワップファイル自体ではなく、スワップファイルが含まれているパーティションのデバイスを指定する必要があることに注意してください。カーネルパラメータ {{ic|resume_offset}} は resume デバイス上に存在するスワップファイルの開始位置を示しています。カーネルパラメータを有効化するために、ハイバネーションをする前に再起動が必要です。
-* [[uswsusp]] を使う場合、キー {{ic|resume device}} と {{ic|resume offset}} を使って {{ic|/etc/suspend.conf}} にこれら2つのパラメータを記述してください。この場合再起動は必要ありません。
+* [[uswsusp]] を使う場合、{{ic|resume device}} キーと {{ic|resume offset}} キーを使って {{ic|/etc/suspend.conf}} に上記2つのパラメータを記述してください。この場合再起動は必要ありません。
 }}
-{{Tip|RAM 利用の拡大ではなく単にハイバネートを可能にしたい場合は、スワップファイルの [[スワップ#Swappiness]] を減らすこともできます。}}
+{{Tip|スワップファイルを作成する目的が、仮想メモリの拡張ではなくハイバネートがしたいだけの場合、スワップファイルの [[スワップ#Swappiness|Swappiness]] を減らすとよいでしょう。}}
 === initramfs の設定 ===
-* [[initramfs]] で {{ic|base}} フックを使っている場合 (Arch ではデフォルトで使っています)、{{ic|/etc/mkinitcpio.conf}} に {{ic|resume}} フックを追加する必要があります。ラベルか UUID に関わらずスワップパーティションは udev デバイスノードとともに参照されるので、{{ic|resume}} フックは必ず {{ic|udev}} の後に続けて下さい。次の例はデフォルトのフック設定から始まっています:
+* [[initramfs]] で {{ic|base}} フックを使っている場合 (Arch ではデフォルトで使っています)、{{ic|/etc/mkinitcpio.conf}} に {{ic|resume}} フックを追加する必要があります。ラベルあるいは UUID どちらを使用している場合でもスワップパーティションは udev デバイスノードによって参照されるので、{{ic|resume}} フックは必ず {{ic|udev}} の後に追加してください。デフォルトのフック設定に {{ic|resume}} フックを追加すると以下のようになります:
 :{{bc|1=HOOKS="base udev '''resume''' autodetect modconf block filesystems keyboard fsck"}}
-:これらの変更を有効化するために [[mkinitcpio#イメージ作成とアクティベーション|initramfs の再生成]]を忘れずに行ってください。
+:変更を適用するために [[mkinitcpio#イメージ作成とアクティベーション|initramfs の再生成]]を忘れずに行ってください。
-:{{Note|[LVM] を使っているユーザーは {{ic|resume}} を {{ic|lvm2}} の次に追加してください。}}
+:{{Note|[LVM] を使っている場合は {{ic|resume}} フックを {{ic|lvm2}} の後に追加してください。}}
-* {{ic|systemd}} のフックで initramfs を使う場合は既に復帰機構が提供されているので、さらにフックを追加する必要はありません。
+* initramfs で {{ic|systemd}} フックを使っている場合は、復帰機構が既に提供されているので、フックを追加する必要はありません。
 == トラブルシューティング ==
@@ 131行目: / 131行目: @@
 {{ic|1=acpi_sleep=nonvs}} カーネルフラグをブートローダに追加してください、これで OK です!
+=== サスペンド/ハイバネートが動作しない、あるいはたまに動作しなくなる ===
-=== Suspend/hibernate doesn't work, or not consistently ===
+サスペンドやハイバネートをした場合、あるいは復帰した場合に画面が表示されなくなるという報告が多数存在します。ノートパソコンとデスクトップの両方で問題は確認されています。正式な解決方法ではありませんが、古いカーネル、特に LTS カーネルに切り替えることで問題は解決することがあります。
-There have been many reports about the screen going black without easily viewable errors or the ability to do anything when going into and coming back from suspend and/or hibernate. These problems have been seen on both laptops and desktops. This is not an official solution, but switching to an older kernel, especially the LTS-kernel, will probably fix this.
+initramfs からのデバイスの初期化によって画面が表示されなくなっていることもあります。[[Mkinitcpio#MODULES]] に追加したモジュールを削除して initramfs を再生成することで問題が解決するかもしれません。特にグラフィックドライバの[[Kernel_Mode_Setting#Early_KMS_start|モジュール]]は問題を起こしがちです。復帰するまえにデバイスが初期化されると矛盾状態になってシステムがハイバネートから復帰できなくなります。サスペンドからの復帰の場合は関係ありません。サスペンドやハイバネートの問題をデバッグする際のベストプラクティスが [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues こちらの記事] に記載されています。
-Sometimes the screen goes black due to device initialization from within the initramfs. Removing any modules you might have in [[en2:Mkinitcpio#MODULES|Mkinitcpio#MODULES]] and rebuilding the initramfs, can possibly solve this issue, specially graphics drivers for [[en2:Kernel_mode_setting#Early_KMS_start|early KMS]]. Initializing such devices before resuming can cause inconsistencies that prevents the system resuming from hibernation. This does not affect resuming from RAM. Also, check this [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues article] for the best practices to debug suspend/hibernate issues.
 === Wake-on-LAN ===
@@ 141行目: / 141行目: @@
 [[Wake-on-LAN]] が有効になっている場合、コンピュータがハイバネート状態になっていてもネットワークインターフェイスカードによって電力が消費されます。
+=== サスペンドからすぐに復帰する ===
-=== Instantaneous wakeups from suspend ===
+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]。
-For some Intel Haswell systems with the LynxPoint and LynxPoint-LP chipset, instantaneous wakeups after suspend are reported. They are linked to erroneous BIOS ACPI implementations and how the {{ic|xhci_hcd}} module interprets it during boot. As a work-around reported affected systems are added to a blacklist (named {{ic|XHCI_SPURIOUS_WAKEUP}}) by the kernel case-by-case.[https://bugzilla.kernel.org/show_bug.cgi?id=66171#c6]
+サスペンド中に USB デバイスを接続したときなどに ACPI の復帰トリガーが有効になって復帰してしまいます。ブラックリストに追加されるまで一時的な応急処置としては復帰トリガーを無効化する方法があります。以下の設定で USB による復帰を無効化することができます [https://bbs.archlinux.org/viewtopic.php?pid=1575617]。
-Instantaneous resume may happen, for example, if a USB device is plugged during suspend and ACPI wakeup triggers are enabled. A viable work-around for such a system, if it is not on the blacklist yet, is to disable the wakeup triggers. An example to disable wakeup through USB is described as follows.[https://bbs.archlinux.org/viewtopic.php?pid=1575617]
+現在の設定を確認:
-To view the current configuration:
 {{hc|$ cat /proc/acpi/wakeup|
@@ 158行目: / 158行目: @@
 }}
-The relevant devices are {{ic|EHC1}}, {{ic|EHC1}} and {{ic|XHC}} (for USB 3.0). To toggle their state you have to echo the device name to the file as root.
+問題のデバイスは {{ic|EHC1}}, {{ic|EHC1}}, {{ic|XHC}} (USB 3.0) です。状態を変更するには root でデバイス名をファイルに echo してください:
  # echo EHC1 > /proc/acpi/wakeup
@@ 164行目: / 164行目: @@
  # echo XHC > /proc/acpi/wakeup
+上記のコマンドでサスペンドが再度機能するようになります。ただし、設定は一時的なものなので再起動するたびに設定し直す必要があります。自動化したい場合は [[systemd#カスタム .service ファイルを書く]]を見てください。詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617 BBS スレッド] を参照。
-This should result in suspension working again. However, this settings are only temporary and would have to be set at every reboot. To automate this take a look at [[en2:systemd#Writing unit files|systemd#Writing unit files]]. See [https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617 BBS thread] for a possible solution and more information.