|
次のページ
前のページ
目次へ
2. コンパイルとインストール2.1 前提条件とカーネルのセットアップドライバのバージョンは2つあります。ひとつは 2.4.0-test3 よりも前のカーネルに 含まれるバージョンです。以下、no-AML-interpreter バージョンと 呼ぶことにします。これは 2.4.0-test3 および、それ以降のカーネルのバージョンで CONFIG_ACPI_INTERPRETER に N と応答し実行したバージョンと同じです (以下の コンフィグレーションオプションズを参照のこと)。もうひとつは 2.4.0-test3 および、それ以降のカーネルで CONFIG_ACPI_INTERPRETER に Y と応答し実行した バージョンです。以下、includes-AML-interpreter バージョンと 呼ぶことにします。このドキュメントを読むに当たって、あなたが使用される ドライバがどのバージョンかを知っておく必要があるでしょう。 一番新しいカーネル (2.4.0-xxx) を手に入れることから始めるべきです。初期の カーネルのバージョンに含まれる初期のドライバのバージョンは、一番新しい acpid や pmtools との動作が保証されていません。しかも acpid や pmtools の パッケージで入手できるバージョンは、最新のものしかありません。 カーネルをビルドするのに必要なすべてのパッケージの更新を必ず行って ください (そのための情報がカーネルソースツリーの中の "Documentation/Changes" というファイルにありますので、参照して ください)。 Linux カーネルのビルドについてのもっと一般的情報は "Kernel-HOWTO" を参照してください。Linux HOWTO は Linux Documentation Project を含むたくさん のサイトで維持されています。Linux Documentation Project の URL は、 http://www.ldp.org/ です。 ACPI サポートのためには、カーネルのリビルドが必要です。 CONFIG_ACPI オプションに Y と答えてください。(今のところ)実験的な サポートですが、スリープモードを組み込みたい場合、 CONFIG_ACPI_S1_SLEEP オプションにも Y と答えればいいです。 APM サポートを無効にする必要はありません――ACPI サポートは実行時に APM サポートを見つけると、実行しているカーネルが自動的にオフにします。 2.4.0-test3 かそれ以降のドライバの新しいインターフェースを試したいのなら、 CONFIG_ACPI_INTERPRETER に Y と答えればいいです。これにより、 "AML interpreter" が正しく組み込まれ、 /proc/sys/acpi インターフェース内にもいくつかの変更が行われます。 コンフィグレーションの後に、いつものようにカーネルをビルドしインストールして ください。 /proc/sys/acpi の試験をすることによって、ドライバのテストができます―― /proc/sys/acpi が存在しないなら、たぶんカーネルが正しく構成されていません。 存在しているなら、以下のように見えなければなりません。 includes-AML-interpreter ドライバを使っている場合
no-AML-interpreter ドライバを使っている場合
どちらのドライバを使っていても、スリープオプションでコンパイルしたなら、
も見えなければなりません。 no-AML-interpreter ドライバを使っているなら
次のコマンドを試すことができます。
文字が 'FACP' で始まり、数バイトの文字化けの後に OEM 名が表示されます。もし、 これが見えたならドライバはBIOSから適正なテーブルを見つけたと言うことなので、 うまくいくかもしれません。 見えないなら、ブートオプション (またはモジュールオプション) のひとつを設定する 必要があるかもしれません。これについてはドライバオプションのセクションで 記述しています。 includes-AML-interpreter ドライバを使っているなら
/proc に見るべきものはあまりありません。/var/log/messages 内の 'ACPI: ACPI support found' の行をチェックできます――この行が見えたなら、 FACP を含むすべてのテーブルはロードされ、AML namespace のロードも同様に 成功しています。 しかしながら、この行の後の方に 'ACPI: enable failed' という行があったなら、 イベントか SCI ハンドラの設定か、ACPI モードへのシステム移行で問題があった ことを意味します。なので、システムは ACPI イベントを処理できません。 ログエントリのもっと詳細な議論はセクション XXX にあります。
2.2 acpid と acpictl のビルドとインストールACPI サポートしたカーネルをビルドしたら、すぐに適切な acpid のバージョンを ダウンロードしてください。includes-AML-interpreter ドライバを使っているなら acpid-071100.tar.gz を、違うなら acpid-052200.tar.gz をダウンロードしなければ なりません。 パッケージをビルドしたいディレクトリを作成します。cd でディレクトリの中に入り、 アーカイブを unpack するコマンドを与えます。
xxx はダウンロードしたパッケージのバージョンです。 同じディレクトリで、
と入力すると、パッケージの構成が行われます。
とするとビルドが行われ
とするとインストールされます。既定のインストールディレクトリが /usr/local で あることに注意してください――ファイルをインストールする場所を他に選ぶなら、 パッケージの構成で次のようにする必要があります。
(訳注:/new/place/to/put/them を好みの場所に置きかえて入力します。) インストールされるプログラムは acpid と acpictl です。既定では、acpid は /usr/local/sbin に、acpictl は /usr/local/bin に置かれます。現時点で これらの man ページは入手できないので、それぞれのプログラムのクィックサマリを ここに記載します。 includes-AML-interpreter ドライバを使っているなら、この項を読んでください。
acpid は ACPI イベントを監視し、処理するデーモンです――ユーザの要求の監視と ドライバへの送信も行います。以下のオプションを受け付けます。
acpictl は acpid と通信するためのユーザクライアントです。以下のオプションを 受け付けます。
実のところ intermediary オプションは、現在何もしていません :-) no-AML-interpreter ドライバを使っているなら、この項を読んでください。
acpid は ACPI イベントを監視し、処理するデーモンです――ユーザの要求の監視と ドライバへの送信も行います。以下のオプションを受け付けます。
tty から引き離さず debug オプションを使用した acpid の実行は、対話式で 各種のコマンドを指定することをユーザに許します。コマンドのリストは debug モードにおいて 'help' コマンドを与えることで見ることができます。
acpictl は acpid と通信するためのユーザクライアントです。以下のオプションを 受け付けます。
実のところ intermediary オプションは、現在何もしていません :-)
2.3 pmtools のコンパイルとインストールpmtools パッケージ内のいくつかのユーティリティの実行には perl が必要です。 確実に一番新しい pmtools のバージョンをダウンロードしてください。パッケージを ビルドしたいディレクトリを作成します。cd でディレクトリの中に入り、 アーカイブを unpack するコマンドを与えます。
xxx はダウンロードしたパッケージのバージョンです。 同じディレクトリで、
と入力すると、パッケージのビルドが行われます。 ユーティリティをインストールする機能は未だ提供されていないので、手動で適切な 場所にユーティリティをコピーします。
または好みのディレクトリにインストールしてもいいです。 このパッケージも文書が提供されていないので、クィックサマリをここに記載します。 acpidmp は root か suid を設定して実行しなければなりません (マルチユーザ システムとして稼動しているなら、root で実行したほうがいいです。それにしても 何でマルチユーザシステムに開発カーネルをインストールしてるの?)。 acpidmp は ACPI BIOS によって提供されるテーブルを捜し、指定された標準出力 (stdout) にダンプします。テーブルは FACP, DSDT, RSDT と名づけられています。 これらのテーブルの内部を知りたいのなら、ACPI バージョン 1.0b の仕様を見て ください。名前を与えず acpidmp を実行した場合、テーブルのすべてを捜し、 標準出力にダンプします。この場合、コマンドラインでは応答しない RSDP も見ること ができます。 acpidmp は人間が読み取れる出力を作成しません。読めるようにするには、パイプで acpidisasm に渡す必要があります。著者の Sony VAIO F420 での例を示します。
作成された出力は
です (3800 行ぐらいの出力があるので、休憩してもいいですよ)。 上記は DSDT テーブルを検索した AML の実際の解読結果です。 no-AML-interpeter ドライバを使っているなら、AML 無しでテーブルのヘッダの参照と 登録のために acpitbl を使用できます――acpitbl は /proc エントリを参照します。 /proc エントリはカーネルで AML interpreter が有効になっていると利用でき ません。著者の laptop の例を示します。
とすれば、出力は
となり、これは dsdt テーブルのヘッダです。 FACP テーブルも同じ方法で調べられます。
著者の laptop では
と見えます。あなたも同じエントリ名が見えるはずですが、値は異なるかも しれません。 もう一つの方法として、includes-AML-interpreter ドライバを使っているなら、/proc から読む代わりに、一番確かな /dev/mem からテーブルを読むことができます。それは
とすると、実際の値に非常に近い結果が得られます。CONFIG_ACPI_INTERPRETER に Y と答えた場合のみ利用できる方法です。 pmtest はデバイスドライバの作者用です。作者が作者のドライバに異なる スリープ状態のサポートを追加する時に使用します。 pmtest は /proc 内に以下のエントリをセットアップするカーネルモジュールです。
このインターフェースを読むことで、どのデバイスが電源管理のために登録されて いるのか、そして、そのデバイスがどの状態にいるのか、調べることができます。 各々のデバイスについて、次の3つの項目を全部書き出しています。
state は 0-3 で、D0-D3 のデバイスの状態に対応します。 devicetype は 0-5 で、/usr/include/linux/pm.h に列挙されたデバイスタイプに 対応します。 deviceid も /usr/include/linux/pm.h に記載された内の一つに対応します。
このファイルに書くことで、/proc/driver/pmtest/devices で一覧表示される デバイスの一つをサスペンド状態 (D0-D3 の一つ) に置くことができます。 /proc/driver/pmtest/devices を見た時と同じように、前述した次の3つの項目を 書かなければなりません。
今まで説明したカーネルモジュール pmtest を直接使用する代わりに、同じ ディレクトリ (既定では /usr/local/bin) にある perl スクリプトの pmtest を 使うべきです。なぜ?それは、簡単だし、便利だし、それから (ほとんどのコマンドで) デバイスの ID とタイプを数値に変換しなくてもいいから です。 insmod と rmmod があなたの path にあることを確認してください。スクリプトは root で実行してください。pmtest はモジュールをロードし、与えられたコマンドを 実行し、それからモジュールをアンロードする、とてもテストには便利なものです。
使用法: pmtest [OPTION] [TYPE] [ID] OPTION は次の一つです。 -l デバイスの一覧表示 (既定値) -d0 デバイスをリジューム (ACPI D0) -d1, -d2, -d3 デバイスをサスペンド (ACPI D1-D3) TYPE は次の一つです。 unknown PCI USB SCSI ISA system ID は次の一つです。 keyboard serial irda floppy vga pcmcia あるいは /usr/include/linux/pm.h にあるデバイスの数値を指定します。
例として: pmtest -l PCI PCI として登録されたデバイスの一覧表示 pmtest -d0 VGA コンソールをリジューム (見えるように) pmtest -d3 PCI 0x1234 ある PCI デバイスをサスペンド (ACPI をオフにした) 著者の laptop を例にすると、以下のように見えます。
2.4 ドライバオプションincludes-AML-interpreter ドライバを使っているなら、実行時のオプションは ありません。 no-AML-interpreter ドライバを使っているなら、ACPI ドライバは (モジュールまたはカーネルブートでの) 実行時に以下のオプションを サポートします(訳注:既定値の説明は省略された場合、このオプションが セットされているのかオフなのかを意味します)。
2.5 システムリソースの設定pci ドライバが ACPI デバイスの適切な割込みの pin を見つけることができないなら ブートオプションとして、カーネルに pci=biosirq を指定する必要があるかも しれません。通常カーネルは IRQ ルーティングテーブルのために確保された メモリ領域の中から PCI 割込みのためのテーブルを探します。しかし、テーブルが 見つからない場合、pci=biosirq オプションをセットすれば、カーネルは PCI BIOS から同じ情報を得ようとします。 まれなケースで ACPI 割込みが既にシステムに構成したいくつかの他のデバイスと 衝突してるかもしれません。衝突したデバイスを無効にするか、それを再構成するか してみてください。割込みの衝突をチェックするには
とし、その出力を調べてください。ただし PCI デバイスだけは、ACPI デバイスと 割込みを共有することができます――他のすべてのデバイスは、いくつかの他の 割込みを使用しなければなりません。例として、著者のサンプル出力を記載します。
/proc/pci をちょっと調べると、2つの Ricoh デバイスが PCI バスの カードバスブリッジにあるのが見えています。このように PCI デバイスは気楽に同じ 割込みを共有できます。 あるユーザは IRQ 13 上に ACPI と fpu が見えていると報告してきました――これは 本物の衝突のケースで、デバイスを正常に機能させたいなら、衝突を解決しなければ なりません。
次のページ 前のページ 目次へ |
[ |