Linux実験コーナー
Back to Index of Linux on VAIO

APM一連の情報は、/proc/apmのファイルに書き出されている。
ちょっとバッテリーを使った時は
$ cat /proc/apm
1.2 1.1 0x03 0x00 0x00 0x01 70% 7560 sec
であったし、バッテリーを充電めいっぱいしたときは
$ cat /proc/apm
1.2 1.1 0x03 0x01 0x03 0x09 100% 10800 sec
と言った具合に確認は簡単だ。
（もちろんユーティリティを使うのが楽。）

さて、これらのデータの内、70%や100%はバッテリーの電圧の最大電圧に対する割合、7560 secや10800 secは使用できる残り時間を示している。しかし、この残り時間の表示がどの程度正確なのかは、実際に何度か試してみなくてはならない。というか、どう考えても100%で3時間も持つはずがない。またさらに、具体的な節電方法は、本体のBIOSにおいて設定されているので、本当にバッテリーの有効利用を考えるならば、そのBIOSの設定をも、考慮せざるを得ない。

とりあえず、PCMCIAのEthernetCardを利用したまま、バッテリー駆動を行ってみた。
基本的にEmacsでのエディット、ktermでのファイル処理、Netscapeによる閲覧や検索、など、端末的な作業を続けてみたところ、ほぼ1時間強程度のバッテリーの持ち具合である。バッテリーのパーセンテージの変化は一律では無い感じもするので、いずれその時間経過による変化を追ってみたい。（参照：バッテリーの時間依存性）

バッテリーが10%に近付くとおそらくBIOSの設定によるのか、幾つかのビープ音とともに本体のバッテリーランプと起動ランプとが一斉に点滅し始めた。
これはまさにバッテリー切れが近いことを示している。
おおよそ8%がそのデッドラインのようだ。
さらに使用を続けるとハイバネーションへ入るはずなのだが、その時点でフリーズしてしまった。

ざっとみたところ、残り時間の減少速度は、実際の時間経過にくらべ1.5倍程速い。一概にこの残り時間の表示を信じるわけにはいかないし、その実、全く意味をなさないことがわかる。 この残り時間はただ、100%のとき3時間として、1%が108秒に対応しているだけのようだ。

さて、節電に関してユーザーが気楽に行えるのは、
サスペンドやハイバネーションだろう。
早速、外部電源を外して、実験開始。

サスペンドに入る方法はパワーキーを一瞬いれれば良い。
もしくはFn + Escのキーコンビネーションでも良いし、 もしapmdがインストールされていれば
# apm -s
でサスペンドする。
すると本体が稼働状態であることを示すパームレスト手前のグリーンランプが、赤く変化、さらに点滅し、サスペンド状態にあることを表す。
あと、何かキーを押せばレジュームされて復帰する。
とりあえずサスペンドおよびレジュームは問題なくできている模様。

そのまま使用を続ける。バッテリーの残りが10%を切ったところで、アラームがなり、電源が危機的状況にあることを示した。更に起こしたままにしていると、そのままフリーズしてしまった(前述)。この原因として、自動的にサスペンドに入るのに失敗したか、ハイバネーションしようとして凍ったのではないか。どちらかと言うとハイバネの方が怪しいか。

節電のモードを仕切っているのは、LinuxのAPMではなく、どう考えてもBIOSのようなので、BIOSモードに突入して、設定を変えてみることにした。
BIOSの設定モードにはいるには、起動直後、「VAIO」の文字が出ている間にf2を押せば良い。

現在、バッテリーが極端に少なくなった時だけハイバネするようにBIOSを設定している。さらには5分でCPUのサイクリング、10分でサスペンドするように設定している。

そこで、バッテリーで走らせたままにしてほっておいた。設定により、10分たてばサスペンドしてくれればいいのだが、約5分後に画面が暗くなったものの、1時間近くそのまま、すなわちサスペンドしない状態であった。結局、1時間程度たった時点で、残りのパーセンテージが10%を切ったので、バッテリーから外部電源に変更した。
このことから、CPUのサイクリングや、自動的なサスペンドの実行などBIOSが絡んでいる節電効果はほとんどないことがわかる。

では続いてサスペンド状態の安定性の確認実験をやろう。
今回PCMCIAなど外部との接続は一切たったまま行う。
サスペンド状態に落して、外部電源はつないだまま、長時間(7時間)ほっておいた。

結果はまったく異常無かった
サスペンド前の画面に復帰し、作業を続けることが出来た。

続いて、サスペンドに関しては同じ設定にして、15分でハイバネするようにBIOSの設定を書き換えた。今回も外部電源はさしたまま、サスペンド状態にする。

約6時間ほどほっておいた。
気がつくと、再びグリーンランプが点灯しており(すなわち起動状態)
あわててディスプレイを覗くとサスペンドから抜けている。しかし、フリーズしており、一切のキー操作やポインティングデバイスの受付けを拒否されてしまった。仕方無く強制終了した。

一体何がおきたのか。
前回の経験から、サスペンドは比較的安定している。
よって、一定時間がたったのでハイバネしようとして失敗したのか?。
最初の実験の時でも、最後の最後で凍っている。おそらく今回と同じ原因だと考えられる。
やはり、よくわからん。

もう一度条件をはっきりさせてから考えてみよう

１）

BIOSの設定
　　　5分後 ：CPUサイクリング
　　　10分後：自動サスペンド
　　　自動ハイバネーションなし
　　　バッテリー低下時：ハイバネーションを実行
結果
　　　CPUサイクリングは未確認、自動サスペンドは発生しない。
　　　手動サスペンドおよびレジュームは、有効。
　　　バッテリーが切れる時、フリーズ。ハイバネーション失敗か?

２）

BIOSの設定
　　　5分後 ：CPUサイクリング
　　　10分後：自動サスペンド
　　　15分後：自動ハイバネーション
　　　バッテリー低下時：ハイバネーションを実行
結果
　　　１）と同じく自動サスペンドは発生せず。
　　　手動サスペンドおよびレジュームは有効。
　　　しかし、サスペンド状況を継続中、復帰状態でフリーズ。

以上のことから、
　　１）のときはバッテリー切れの時のハイバネーション、
　　２）のときはサスペンド中のCPU機能低下の状態が15分続いたことによる、自動ハイバネーション、
によってそれぞれフリーズが引き起こされている。

分かった、ハイバネーションがうまく行かないのだ。
なぜだろう?
Winの方では問題なくハイバネ出来ていたのに。

考えられる理由の一つとして、ハイバネーションに使われるハードディスクの問題があげられる。ハイバネーション用のディスク領域がどこに作られるかが、結構重要なのではないか。
例えば、FAT32の領域にハイバネ用領域が作られるとすると、Linuxからはたしてその領域へ書き込むことが出来るのか？という疑問がでる。
確かに、現在のKernel2.0.35ではすでにFAT32に対応しており、FAT32領域もマウント出来る。と、言って書き込むことが出来るかどうかは分からない。

また一方で、ハイバネーション用の領域というのは、現在走っているOSに支配されているのかも知れない。すなわち、Winが走っていればWinの支配下にあるFAT32領域に保存されるし、Linuxならそのext2fs領域に保存されるのかも知れない。現時点では僕のマシンのハードディスクのlinuxの領域はハイバネが出来る程、スペースに余裕が無い。以前、Winの上でHDのまとまった空き容量が無いとハイバネ出来なかったことがあったので、今回のハイバネ失敗が、ハードディスクの容量に関係しているとすると、しばらくはこの実験を見合わせるしかない。

ちなみに、BIOS設定ではハイバネーションのディスク領域についての設定はない。