「電源管理/サスペンドとハイバネート」の版間の差分
201行目: | 201行目: | ||
=== サスペンド/ハイバネートが動作しない、あるいはたまに動作しなくなる === |
=== サスペンド/ハイバネートが動作しない、あるいはたまに動作しなくなる === |
||
− | + | ハイバネートやサスペンドから復帰した時に画面が真っ暗になって、明確なエラーは表示されず、何もできなくなるという報告が多数存在します。これらの問題は、ノートパソコンとデスクトップの両方で確認されています。公式の解決方法ではありませんが、古いカーネル、特に LTS カーネルに切り替えることで問題が解決することがあります。 |
|
+ | ハードウェアの watchdog タイマーを使用している場合に問題が起こることもあります(デフォルトで無効化されています、{{man|5|systemd-system.conf|OPTIONS}} の {{ic|1=RuntimeWatchdogSec=}} を見てください)。バグを起こした watchdog タイマーにより、システムがハイバネートイメージの作成を終える前に、コンピュータがリセットされることがあります。 |
||
− | initramfs からのデバイスの初期化によって画面が表示されなくなっていることもあります。[[Mkinitcpio#MODULES]] に追加したモジュールを削除して initramfs を再生成することで問題が解決するかもしれません。特にグラフィックドライバの[[Kernel_Mode_Setting#Early_KMS_start|モジュール]]は問題を起こしがちです。復帰するまえにデバイスが初期化されると矛盾状態になってシステムがハイバネートから復帰できなくなります。サスペンドからの復帰の場合は関係ありません。サスペンドやハイバネートの問題をデバッグする際のベストプラクティスが [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues こちらの記事] に記載されています。 |
||
+ | |||
+ | initramfs からのデバイスの初期化によって画面が表示されなくなっていることもあります。[[Mkinitcpio#MODULES]] に追加したモジュールを削除して initramfs を再生成することで問題が解決するかもしれません。特にグラフィックドライバの [[Kernel_Mode_Setting#Early_KMS_start|早期 KMS]] は問題を起こしがちです。復帰するまえにデバイスが初期化されると矛盾状態になってシステムがハイバネートから復帰できなくなります。サスペンドからの復帰の場合は関係ありません。サスペンドやハイバネートの問題をデバッグする際のベストプラクティスが [https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues こちらの記事] に記載されています。 |
||
+ | |||
+ | [[radeon]] ビデオドライバから新しい [[AMDGPU]] ドライバに変更すると、ハイバネートとハイバネートからの復帰のプロセスが成功するかもしれません。 |
||
+ | |||
+ | Intel グラフィックドライバの場合は、早期 KMS を有効化することにより、真っ暗な画面の問題を解決できることがあります。詳細は [[Kernel_Mode_Setting#Early_KMS_start]] を見てください。 |
||
+ | |||
+ | カーネル 4.15.3 にアップグレードした後に、サスペンド/ハイバネートからの復帰に失敗し、真っ暗な画面でカーソルが固まる(点滅はしない)ようになることがあります。{{ic|nvidiafb}} モジュールを[[ブラックリスト]]に追加すると解決するかもしれません。[https://bbs.archlinux.org/viewtopic.php?id=234646] |
||
+ | |||
+ | Intel CPU を搭載していて、タッチパッドのために {{ic|intel_lpss_pci}} をロードするノート PC では、復帰時にカーネルパニックを引き起こすことがあります(この時、caps lock が点滅する) [https://bbs.archlinux.org/viewtopic.php?id=231881]。このモジュールは、以下のように [[initramfs]] に追加する必要があります: |
||
+ | |||
+ | {{hc|head=/etc/mkinitcpio.conf|output= |
||
+ | MODULES=(... intel_lpss_pci ...) |
||
+ | }} |
||
+ | |||
+ | そして、[[initramfs を再生成する|initramfs を再生成]]してください。 |
||
=== Wake-on-LAN === |
=== Wake-on-LAN === |
2022年8月6日 (土) 20:35時点における版
現在サスペンドには3つの手法が存在します:
- Suspend to RAM (サスペンド、スリープとも呼ばれます)
- ACPI で S3 スリープ状態として定義されています。RAM を除くマシンのほとんど全てのパーツの電源を切ります。RAM への電源はマシンの状態を保存するために必要です。電力を多く節約できるので、ラップトップでは、バッテリーでコンピュータが稼働していてフタが閉じられた時 (もしくはユーザーが長い間操作しなかった時) は自動的にこのモードに移行するのが得策でしょう。
- Suspend to disk (ハイバネートとも呼ばれます)
- ACPI で S4 スリープ状態として定義されています。マシンの状態をスワップ領域に保存してマシンの電源を完全にオフにします。マシンに電源を入れた時、状態が復元されます。それまでは、電力消費量はゼロです。
- Suspend to both
- 前述の2つの手法のハイブリッドです。ハイブリッドサスペンド と呼ばれることもあります。マシンの状態をスワップ領域に保存しますが、マシンの電源を切りません。代わりに、通常の suspend to RAM を呼び出します。これによって、バッテリーを使いきっても、システムを RAM から復帰することが可能です。バッテリーが枯渇した時は、システムはディスクから復帰し、RAM からの復帰に比べて時間がかかりますが、システムの状態が失われることはありません。
基本的な機能を提供する低レベルなインターフェイス (バックエンド) が複数存在し、問題のあるハードウェアドライバ/カーネルモジュール (例: ビデオカードの再初期化) を扱う機能を提供する高レベルなインターフェイスもいくつかあります。
低レベルインターフェイス
これらのインターフェイスは直接使うこともできますが、通常は高レベルインターフェイスを使ってサスペンド・ハイバネートを行うとよいでしょう。低レベルなインターフェイスを直接使うと、サスペンドの前や後に行うフック処理を全て実行する高レベルインターフェイスよりもかなり早くサスペンドが可能です。ただしフックはハードウェアクロックの設定や、ワイヤレスの復旧などを正しく処理することができます。
カーネル (swsusp)
直球の方法はカーネル内のソフトウェアサスペンドコード (swsusp) にサスペンド状態に入るよう直接伝えることです。実際の方法と状態はハードウェアサポートのレベルによります。最近のカーネルでは、サスペンドにするために /sys/power/state
に適切な文字列を書くことが主な方法になっています。
詳しくは カーネルドキュメント を参照してください。
uswsusp
uswsusp ('Userspace Software Suspend') はカーネルの suspend-to-RAM のラッパーで、サスペンドの前と復帰の後にユーザー空間からグラフィックアダプタの操作を行います。
Uswsusp の記事を参照してください。
高レベルインターフェイス
これらのパッケージではサスペンド/ハイバネートを行うためのバイナリ/スクリプトを提供します。実際に電源ボタンやメニュークリック、ラップトップのカバーのイベントなどと結びつけるのは他のツールで行うのが通常です。(ラップトップのカバーが閉じられたり、バッテリーが枯渇するなど)特定の電源イベントで自動的にサスペンド/ハイバネートをするには、Acpid の実行について調べて下さい。
systemd
systemd はサスペンド・ハイバネート・ハイブリッドサスペンドを行うためのネイティブのコマンドを提供しています。詳しくは 電源管理#systemd による電源管理 を見て下さい。これは Arch Linux で使われているデフォルトのインターフェースです。
サスペンド・ハイバネートのフックの設定に関する情報は電源管理#スリープフックに載っています。man systemctl
, man systemd-sleep
, man systemd.special
もあわせて参照してください。
ハイバネーション
ハイバネーションを使うには、スワップパーティションかスワップファイルを作成する必要があります。そして resume=
カーネルパラメータを使ってスワップを指定してください。カーネルパラメータはブートローダで設定します。initramfs の設定も必要になります。設定によってカーネルは初期ユーザー空間で指定されたスワップからの復帰を試みます。以下ではスワップの作成・カーネルパラメータの設定・initramfs の設定について詳細に説明します。
スワップパーティション(ファイル)のサイズについて
スワップパーティションが RAM より小さかったとしても、ハイバネートが成功する可能性は高いと思われます。image_size
sysfs(5) 疑似ファイルに関する情報は カーネルドキュメントの "image_size" を見てください。
(スワップパーティションを小さくして) /sys/power/image_size
の値を減らしてサスペンドのイメージを出来る限り小さくすることも、値を増やしてハイバネーションを高速化することも可能です。大きな容量の RAM を搭載しているシステムでは、より小さい値にするとハイバネートからの復帰が劇的に速くなることがあります。image_size
の値を再起動後も保持するために systemd#systemd-tmpfiles - 一時ファイル を使うことができます:
/etc/tmpfiles.d/hibernation_image_size.conf
# Path Mode UID GID Age Argument w /sys/power/image_size - - - - 0
サスペンドイメージは複数のスワップパーティション/スワップファイルにまたがって保存することができません。イメージのすべての部分が1つのスワップパーティション/スワップファイルに収まらなければなりません。[1]
initramfs の設定
- initramfs で
base
フックを使っている場合 (Arch ではデフォルトで使っています)、/etc/mkinitcpio.conf
にresume
フックを追加する必要があります。ラベルあるいは UUID どちらを使用している場合でもスワップパーティションは udev デバイスノードによって参照されるので、resume
フックは必ずfilesystems
の前に追加してください。デフォルトのフック設定にresume
フックを追加すると以下のようになります:
HOOKS=(base udev autodetect keyboard modconf block filesystems resume fsck)
- 変更を適用するために initramfs の再生成を忘れずに行ってください。
- initramfs で
systemd
フックを使っている場合は、復帰機構が既に提供されているので、フックを追加する必要はありません。
必要なカーネルパラメータ
カーネルパラメータ resume=swap_device
を使う必要があります。永続的なブロックデバイスの命名を swap_device
に使用することができます。例:
resume=/dev/sda1
resume=UUID=4209c845-f495-4c43-8a03-5363dd433153
resume=/dev/mapper/archVolumeGroup-archLogicVolume
-- スワップが LVM 論理ボリュームにある場合
カーネルパラメータは再起動後に有効となります。すぐにハイバネートできるようにするには、lsblk を使ってボリュームのメジャーデバイスナンバーとマイナーデバイスナンバーを手に入れて、/sys/power/resume
に major:minor
という形式で書き込んでください。スワップファイルを使用している場合は、追加で /sys/power/resume_offset
に resume オフセットを書き込んでください。[2]
例えば、スワップデバイスが 8:3
の場合:
# echo 8:3 > /sys/power/resume
スワップファイルにハイバネートする場合で、スワップファイルがボリューム 8:2
にあり、オフセットが 38912
の場合:
# echo 8:2 > /sys/power/resume # echo 38912 > /sys/power/resume_offset
スワップファイルにハイバネーション
スワップファイル を使用するには resume=swap_device
だけでなく、resume_offset=swap_file_offset
カーネルパラメータも設定する必要があります。カーネルのドキュメントを見てください。
swap_device
はスワップファイルが存在するボリュームで、root パラメータと同じ形式に従います。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
です。
Btrfs のスワップファイルへのハイバネーション
resume_offset 番号は、tool btrfs_map_physical.c を使用して計算できます。 Btrfs では、 filefrag ツールを使用しないでください。filefrag から取得する "物理" オフセットは、ディスク上の実際の物理オフセットではありません。複数のデバイスをサポートするために、仮想ディスクのアドレス空間があります。[3]
tool btrfs_map_physical.c をダウンロードするか、btrfs_map_physical.c
という名前のファイルにコピーしてからコンパイルします。
$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c
そしてそれを実行します。出力例を以下に示します。
# ./btrfs_map_physical /path/to/swapfile
FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET 0 regular 4096 2927632384 268435456 1 4009762816 4096 prealloc 268431360 2927636480 268431360 1 4009766912 268435456 prealloc 268435456 3251634176 268435456 1 4333764608 536870912 prealloc 268435456 3520069632 268435456 1 4602200064 805306368 prealloc 268435456 3788505088 268435456 1 4870635520 1073741824 prealloc 268435456 4056940544 268435456 1 5139070976 1342177280 prealloc 268435456 4325376000 268435456 1 5407506432 1610612736 prealloc 268435456 4593811456 268435456 1 5675941888
このツールによって返される最初の物理オフセットに注意してください。この例では、4009762816
を使用します。getconf PAGESIZE
で見つけることができるページサイズにも注意してください。
resume_offset
値を計算するには、物理オフセットをページサイズで割ります。この例では、 4009762816 / 4096 = 978946
です。
thinly-provisioned LVM ボリュームへのハイバネーション
thinly-provisioned LVM されたボリュームへの休止状態は可能ですが、ボリュームが完全に割り当てられていることを確認する必要があります。そうしないと、再開に失敗します。FS#50703 を見てください。
LVM ボリュームをゼロで埋めるだけで、 LVM ボリュームを完全に割り当てることができます。 例えば:
# dd if=/dev/zero of=/dev/vg0/swap bs=1M status=progress
ボリュームが完全に割り当てられていることを確認するには、次を使用できます:
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert swap vg0 Vwi-aot--- 10.00g pool 100
完全に割り当てられたボリュームは、100%のデータ使用量であると表示されます。
Intel Rapid Start Technology (IRST)
Intel Rapid Start Technology とは、ハイバネートするためのハードウェア上の方法で、あらかじめ設定された時間やバッテリー状態のあとにスリープからハイバネートに移行できるようにします。IRSTは、オペレーティングシステムのレベルではなくファームウェアによって行われるので、通常のハイバネートよりも速く信頼性が高いはずです。一般的に、IRST はファームウェアで有効化する必要があり、またファームウェアで、サスペンド/バッテリイベント後にハイバネートをトリガーするまでの時間を設定できます。しかし、一部のデバイスは IRST をファームウェアでサポートしていますが、Intel の Windows ドライバからでしか設定できません。そのような場合には、以下で説明している intel-rst カーネルモジュールで Linux でもイベントを設定できるはずです。
Intel Rapid Start Technology (IRST) が有効の場合、deep sleep からの再開には "S3から再開するよりも数秒長くなりますが、ハイバネートから再開するよりもはるかに高速です"。
Intel ベースのシステムの多くは、 IRST のファームウェアをサポートしていますが、(HDD ではなく) SSD 上に特別なパーティションを必要とします。 Windows の OEM 展開では、Arch Linux インストールプロセス中に (SSD 全体を消去して再パーティションするのではなく) 保持できる IRST パーティションがすでに存在している場合があります。システムの RAM と同じサイズの未フォーマットパーティションとして表示されます。
しかし、ドライブ全体を消去してパーティションを切り直すつもりなら (あるいはすでにそうしてしまっているなら) IRST パーティションも再作成しなければなりません。これを行うには、システムの RAM と同じサイズの空のパーティションを作成し、そのパーティションの種類が GPT パーティションの場合は GUID D3BFE2DE-3DAF-11DF-BA40-E3A556D89593
に、 MBR パーティションの場合は ID 0x84
に設定します。また、システムのファームウェア設定で IRST のサポートを有効にする必要がある場合もあります。
IRST ハイバネートにかかる時間 (つまり、"RAMの内容全体を特殊なパーティションに" コピーする時間) は、システムの RAM サイズと SSD 速度によって異なり、20~60秒かかります。システムによっては、プロセスの完了を(点滅を止めるなどして) LED インジケータで示す場合があります。
Linux で IRST ハイバネートイベントを設定するには、CONFIG_INTEL_RST=y
を設定するか、モジュールに設定されているならば intel-rst モジュールがロードされている必要があります。modprobe intel_rst
を実行してモジュールをロードすれば、例えば /sys/bus/acpi/drivers/intel_rapid_start/*/wakeup_events
などのようにファイル wakeup_events と wakeup_time が生成されるはずです。これらを用いて、さらなる設定を行うことができます。このモジュールは簡潔にドキュメント化されています。詳細は drivers/platform/x86/intel/rst.c を見てください。
Intel Rapid Start Technology に関する情報は、general Q&A と user guides も見てください。
トラブルシューティング
ACPI_OS_NAME
DSDT table を動作するように設定することができます。DSDT の記事を参照してください。
サスペンド/ハイバネートが動作しない、あるいはたまに動作しなくなる
ハイバネートやサスペンドから復帰した時に画面が真っ暗になって、明確なエラーは表示されず、何もできなくなるという報告が多数存在します。これらの問題は、ノートパソコンとデスクトップの両方で確認されています。公式の解決方法ではありませんが、古いカーネル、特に LTS カーネルに切り替えることで問題が解決することがあります。
ハードウェアの watchdog タイマーを使用している場合に問題が起こることもあります(デフォルトで無効化されています、systemd-system.conf(5) § OPTIONS の RuntimeWatchdogSec=
を見てください)。バグを起こした watchdog タイマーにより、システムがハイバネートイメージの作成を終える前に、コンピュータがリセットされることがあります。
initramfs からのデバイスの初期化によって画面が表示されなくなっていることもあります。Mkinitcpio#MODULES に追加したモジュールを削除して initramfs を再生成することで問題が解決するかもしれません。特にグラフィックドライバの 早期 KMS は問題を起こしがちです。復帰するまえにデバイスが初期化されると矛盾状態になってシステムがハイバネートから復帰できなくなります。サスペンドからの復帰の場合は関係ありません。サスペンドやハイバネートの問題をデバッグする際のベストプラクティスが こちらの記事 に記載されています。
radeon ビデオドライバから新しい AMDGPU ドライバに変更すると、ハイバネートとハイバネートからの復帰のプロセスが成功するかもしれません。
Intel グラフィックドライバの場合は、早期 KMS を有効化することにより、真っ暗な画面の問題を解決できることがあります。詳細は Kernel_Mode_Setting#Early_KMS_start を見てください。
カーネル 4.15.3 にアップグレードした後に、サスペンド/ハイバネートからの復帰に失敗し、真っ暗な画面でカーソルが固まる(点滅はしない)ようになることがあります。nvidiafb
モジュールをブラックリストに追加すると解決するかもしれません。[5]
Intel CPU を搭載していて、タッチパッドのために intel_lpss_pci
をロードするノート PC では、復帰時にカーネルパニックを引き起こすことがあります(この時、caps lock が点滅する) [6]。このモジュールは、以下のように initramfs に追加する必要があります:
/etc/mkinitcpio.conf
MODULES=(... intel_lpss_pci ...)
そして、initramfs を再生成してください。
Wake-on-LAN
Wake-on-LAN が有効になっている場合、コンピュータがハイバネート状態になっていてもネットワークインターフェイスカードによって電力が消費されます。
サスペンドからすぐに復帰する
復帰トリガー#サスペンドからすぐに復帰する を見てください。
ハイバネートした時にシステムの電源が落ちない
システムをハイバネートした時には、(状態をディスク上に保存したあとに)システムの電源が落ちるべきです。時々、ハイバネートした後も電源 LED が光り続けることがあります。これが起こる場合、sleep.conf.d(5) で HibernateMode
を shutdown
に設定すると問題が解決するかもしれません。
/etc/systemd/sleep.conf.d/hibernatemode.conf
[Sleep] HibernateMode=shutdown
上記の設定により、その他の設定が正しく行われていれば、systemctl hibernate
を実行するとマシンがシャットダウンし、状態をディスクに保存します。