includes-AML-interpreter ドライバを使っているなら、この項を読んでください。
/proc/sys/acpi/c2_exit_latency
/proc/sys/acpi/c3_exit_latency
これらはレベル２かレベル３のプロセッサのスリープ状態 (C2 か C3) から抜け出る ための待ち時間を表します。これらは、次のように使うことができます。" 電源断 %n 経過するまで C2 でスリープ (%n は C3 に移行するまでの待ち時間 として見積られている)・・・"。 最初は無限大に設定されますが、C2 と C3 が有効にされる時に FACP テーブル上の 値によって決定されます。ドライバが BIOS のテーブルを読めず、とあらかじめ定義 した BIOS の変わりのテーブルを信頼するなら、これらの値は無限大のままです。 そのときは、C2 と C3 状態を正常に有効にするためには、自分で妥当な値に変更 しなければなりません。
/proc/sys/acpi/c2_enter_latency
/proc/sys/acpi/c3_enter_latency
これらは C2 か C3 のスリープ状態に入るための待ち時間を表します。 これらは非常に短く一定しています。最初は例外で無限大になっています (だから この状態には、はっきりと有効にするまで入りません)。
/proc/sys/acpi/event
このエントリを読むことで、BIOSによって通知された (有効になっている) ACPI イベントに関連付けられた 16 進数を見ることができます。一つのウィンドウで
cat /proc/sys/acpi/event
とし、もう一つのウィンドウで様々なボタンとキーの組合せを押して見てください。 それらのいくつかが ACPI イベントとして登録されていれば、イベントを見ることが でき、どのように登録されているかわかります。 ドライバはすべてのイベントを有効にしてはいません。現在 no-AML-interpreter ドライバの下で使用できるすべてのイベントを有効にする方法はありません。 ドライバによって電源ボタンが有効になっていても、それは /proc/sys/acpid/event の下のイベントとして見えるだけです。
/proc/sys/acpi/sleep
これに書くことは、システムをスリープ状態に置く現在唯一の方法です――具体的に
echo 1 > /proc/sys/acpi/sleep
とすれば、S1 に入ります。
警告――これをする前に、不要なプロセスを終了してください。ひょとしたら、 目覚めのきっかけに想定されている様々なキーを押すことをシステムは認識しない かもしれません(著者のものは、現在のドライバでキーを押すことを認識しません)。
no-AML-interpreter ドライバを使っているなら、この項を読んでください。
ACPI の /proc エントリのほとんどは、通知です――いくつかは ACPI イベントを 引き起こすのに使えます。それぞれ通知の詳細と使い方を記載します。
/proc/sys/acpi/facp
これは FACP テーブルのヘッダとボディにアクセスすることを許します。これを 読むことで、ACPI の能力と現在の状態を分かるために調査できるテーブルを見る ことができます――書くことで、完全なテーブルのヘッダとボディの差し替え (普通は ドライバにより完了しています) か、一つのレジスタの値の変更、のどちらかが できます。FACP テーブルを読み、それを理解するためには、pmtools パッケージを 使った方がいいでしょう。次のコマンドを実行してください。
acpitbl /proc/sys/acpi/facp
幾分人間の読める形でテーブルのダンプが表示されます。
/proc/sys/acpi/dsdt
これは DSDT テーブルのヘッダとボディにアクセスすることを許します。 例外はありますが、facp エントリの注釈と同じことがいえます。dsdt エントリを 読み、それを理解するには、次のコマンドを実行するといいでしょう。
acpitbl /proc/sys/acpi/dsdt
とすれば、ヘッダが見え、
cat /proc/sys/acpi/dsdt | acpidisasm
とすれば (解釈された) AML を読めます。
/proc/sys/acpi/pm1_enable
このエントリを読むことで、どの電源管理イベントが有効にされているかみることが できます。各々のイベントはビットマスクに対応しています――そのマスクに対応した 値のビットがセットならイベントは有効で、オフならイベントは無効です。ACPI の 実装でサポートしているすべての電源管理イベントを有効にするには、このエントリに "0xffffffff" を書きます。このエントリを呼んだ場合、たぶん値は 0xffffffff ではありません。なぜなら、すべての定義されたイベントがサポート されていないからです (もしサポートされたとすると、すべてのビットは使われる のかな？)。
どのイベントをどのビットマスクに対応させるか決める方法は・・・
/proc/sys/acpi/gpe_enable
このエントリを読むことで、どの汎用イベントが有効にされているかみることが できます。前述の pm1_enable と同じ方法でこのエントリを操作できます。
どのイベントをどのビットマスクに対応させるか決める方法は・・・
/proc/sys/acpi/gpe_level
このエントリを読むことで、汎用イベントがどのレベルなのか見ることが できます――このエントリに書くことはレベルを変更することになります (詳細は セクション 4.7 のチャイルドイベントのビットについての記述を見てください)。
/proc/sys/acpi/event
このエントリを読むことで、BIOSによって通知された (有効になっている) ACPI イベントに関連付けられた 16 進数を見ることができます。gp1_enable と pm1_enable に 0xffffffff を書くことですべてのイベントを有効にしているなら、 次いで一つのウィンドウで
cat /proc/sys/acpi/event
とし、もう一つのウィンドウで様々なボタンとキーの組合せを押して見てください。 それらのいくつかが ACPI イベントとして登録されていれば、イベントを見ることが できます。例えば、これは、電源ボタンが何かを見る一つの方法です。
例として、著者の Sony VAIO で実行した結果を以下に示します。
[root@devel2 kernel]# echo 0xffffffff > /proc/sys/acpi/pm1_enable
[root@devel2 kernel]# echo 0xffffffff > /proc/sys/acpi/gpe_enable
[root@devel2 kernel]# cat /proc/sys/acpi/pm1_enable
0x00000521
[root@devel2 kernel]# cat /proc/sys/acpi/gpe_enable
0x00000f01
(press power button)
[root@devel2 kernel]# cat /proc/sys/acpi/event
0x00000001 0x00000000 0x0
0x00000001 0x00000000 0x0
0x00000000 0x00000200 0x0
電源ボタンの押したことをみることができます――それは cat の最後の行です。
/proc/sys/acpi/p_blk
(仕様によれば) 各々のプロセッサのためにこれらの一つがあります――例えば C2 か C3 の状態にプロセッサを置くような、プロセッサの制御に使われます。 ドライバはある瞬間をとらえると一つのプロセッサだけをサポートしていますので、 /proc インターフェースにはこれらの一つの場所しかありません。ここに直接書く 必要は絶対にありません――一つのスリープ状態からもう一つの状態に切り換える時、 ドライバが書き込みます。
/proc/sys/acpi/p_lvl2_lat
/proc/sys/acpi/p_lvl3_lat
これらはレベル２かレベル３のプロセッサのスリープ状態から抜け出るための 待ち時間を表します。これらは、次のように使うことができます。" 電源断 %n 経過するまで C2 でスリープ (%n は C3 に移行するまでの待ち時間 として見積られている)・・・"。 最初は無限大に設定されますが、C2 と C3 が有効にされる時に FACP テーブル上の 値によって決定されます。ドライバに 'chipset' オプションを使用するなら、 これらの値は無限大に設定され、決して変更しません――C2 と C3 状態を正常に 有効にするためには、自分で妥当な値に変更しなければなりません。同様に、 ドライバがテーブルを見つけることができず、チップセット情報の使用が失敗した なら、自分で値を設定しなければなりません。
/proc/sys/acpi/enter_lvl2_lat
/proc/sys/acpi/enter_lvl3_lat
これらはレベル２かレベル３のスリープ状態に入るための待ち時間を表します。 これらは非常に短く一定しています。最初は例外で無限大になっています (だから この状態には、はっきりと有効にするまで入りません)。
/proc/sys/acpi/s0_slp_typ
/proc/sys/acpi/s1_slp_typ
/proc/sys/acpi/s5_slp_typ
これらは、いくつかの処理の後、正常にシステムを適切なスリープ状態 (S0, S1, S5) に置くために、pm1a_cnt と pm1b_cnt に詰め込む必要のある値を表します。 ドライバはこれらを初期化しません――acpid は BIOS を通してそれらを参照し、 ドライバが受け取った値によってそれらを設定するかドライバにたずねます。 acpid に問題があり直接これらの値を設定したいなら、チップセットによって推測し 試すか、DSDT のダンプ ("acpidmp DSDT | acpidisasm" のコマンドを 使う) の出力から見つけることができます。DSDT のダンプのこの項に関するところは 次のようなものになります。
00000013: Name _S0_ (\_S0_)
00000018: Package
0000001a: 0x04
0000001b: 0x05
0000001d: 0x05
0000001f: 0x00
00000021: 0x00
00000023: Name _S1_ (\_S1_)
00000028: Package
0000002a: 0x04
0000002b: 0x04
0000002d: 0x04
0000002f: 0x00
00000031: 0x00
00000033: Name _S3_ (\_S3_)
00000038: Package
0000003a: 0x04
0000003b: 0x01
0000003d: 0x01
0000003f: 0x00
00000041: 0x00
出力はたくさん続きます。各々のエントリの２番目と３番目のバイトは、下記に示す ログの値に対応します。
acpid が動作しているなら、acpid が起動した時に /var/log/messages に書き込む これらの値を見ることができます。 例として、著者のログエントリは以下のようになっています。
Jun 11 00:51:02 devel2 acpid: S0 SLP_TYP (0x0505)
Jun 11 00:51:02 devel2 acpid: S1 SLP_TYP (0x0404)
Jun 11 00:51:02 devel2 acpid: S2 not supported
Jun 11 00:51:02 devel2 acpid: S3 SLP_TYP (0x0101)
Jun 11 00:51:02 devel2 acpid: S4 SLP_TYP (0x0000)
Jun 11 00:51:02 devel2 acpid: S5 SLP_TYP (0x0000)
そうです、おまけの数値２つを得れますが、現在の proc エントリではありません。
/proc/sys/acpi/sleep
これに書くことは、システムをスリープ状態に置く現在唯一の方法です――具体的に
echo 1 > /proc/sys/acpi/sleep
とすれば、S1 に入ります。
警告――これをする前に、不要なプロセスを終了してください。ひょとしたら、 目覚めのきっかけに想定されている様々なキーを押すことをシステムは認識しない かもしれません(著者のものは、現在のドライバでキーを押すことを認識しません)。
/var/log/messages 内に次のようなメッセージを見るかもしれません。
e820: 000000000000f800 @ 0000000003ff0000 (ACPI data)
e820: 0000000000000800 @ 0000000003fff800 (ACPI NVS)
割込み 15 のサブファンクション e820 は、システムメモリマップを返すために BIOS が引き起こしています。
データ領域は、様々な ACPI テーブルが含まれます。テーブルの使用が終わったとき、 OS はこの領域を取り戻します。
NVS は Non-Volatile-Sleeping Memory の略語です――これは S4 状態に入る前に OS が保存と復旧を行う領域として想定されています。この領域は決して取り 戻されません。
ログ内に ACPI のデータ領域が見えないなら、これはたぶん、ドライバがテーブルを 見つけられなかったことを表します。どうにか動作していると思われるなら、たぶん チップセット固有の情報を使っています。調査のためにブートオプションを試みる ことができます (詳細は セクション 2.4 を見てください)。