FreeBSD が suspend から目覚めたときの動作。

僕が持っている ThinkPad e145 は FreeBSD がインストールされていて、 suspend/resume するんだけど、resume 時、それはつまり目覚めたとき、パカっとフタを明けたときに default gateway が消えていたりして、ネットワーク的にはちょっと問題があったんですね。
まぁ、目覚めたあとにいつも route add していたんですけども。

そんなこんなで、resume 後に route add が必要なわけ、挙動をいよいよ調査してみることにしたんですね。

僕の FreeBSD の環境は以下です。

・FreeBSD/amd64 10.1-RELEASE
・ネットワーク環境は USB 接続の run0 -> wlan0

OS はまたもっと面白いことになってます。カーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。やってはいけない環境で動かしている。と、いうことですね。どうしてこんな環境で動かしているかについてはあとで少しお話します。

今の話題は resume 後に routing テーブルが消えている点についてですね。話を元に戻しましょう。

 
suspend して、その後 resume したときに起き上がってきた FreeBSD の動作ですが、だいたい以下のようになっているようです。

0. 実は suspend 時に USB デバイスが全部抜去される
1. resume 後に USB を認識してデバイスが接続される
2. resume 後に /etc/rc.resume が動く
3. devd が色々良きに計らってくれる (僕の環境では webcamd の再起動と pccard_ether のすーたと)
4. 自分で記述したスクリプトの動作
5. /etc/rc.resume の終了

まぁ、こんな感じですが、問題は 5. ですかね。

suspend で USB 機器が外されたということはつまりは wlan0 が無くなった。と、いうことなので、これで routing テーブルは全て消えます。
その後 resume して USB 機器が接続され wlan0 が認識され、wpa_supplicant が動き出してネットワークインターフェースには IP アドレスが付加されるようになります。

じゃぁ /etc/rc.resume の中で route add すりゃいんじゃね？

とか思うんですが /etc/rc.resume 内で route add してもそのときはまだ wlan0 に IP アドレスが付く前なので意味無いんですよね。

じゃぁ /etc/rc.resume の中で route add する前に sleep 30 とかすりゃいんじゃね？

とか、次に思いますよね。ところがっ!! /et/rc.resume はちょっとおかしな動作をしていて、 /etc/rc.resume が動作し終わったあとに wlan0 に IP アドレスが付加されるようです。

なので /etc/rc.resume の中で

sleep 30
route add default 192.168.1.1
route add -inet6 default fe80::1

などと書いても全く意味ない状態です。では、どうするか？と、いうと、上記の部分をスクリプト、例えば /usr/local/bin/routeadd.sh などとして準備します。
/etc/rc.resume には以下のように書きます。

/usr/bin/logger -t $subsystem route add default.
/usr/local/bin/routeadd.sh &

ここで注意しなければならないのは、スクリプトを記載したあと、最後に “&” を付けてバックグラウンドで処理させる必要があります。
動作的には /etc/rc.resume の実行後に wlan0 に IP アドレスが付くので /etc/rc.resume が実行中に sleep 30 してもまるで意味なくて route add されない状態です。なので “&” を書いてバックグラウンドに飛ばして、バックグラウンドのスクリプトが sleep 30 している間に /etc/rc.resume が終了して wlan0 に IP アドレスが付いたあと、 sleep 30 が終わり route add されるようにしないとダメなのであります。

この現象は USB NIC を利用しているからかもしれません。
動作的に resume 後に routing デーブルが消えていて、毎回、自分で route add 打つのが困難な人は上記のようにすれば良いのではないかと思います。

 
で、もう一個のネタを簡単に。

上のほうにも書きましたが、僕の ThinkPad e145 上で動作している FreeBSD はカーネル は 10.1-RELEASE でユーザランドが 10.3-RELEASE です。これ、FreeBSD の動作保証対象外の構成らしいですね。カーネルは新しく、ユーザランドが古い場合には問題ないらしいですが・・。

どうしてこんな環境で動かしているかというと ThinkPad を使っている人は 10.2-RELEASE 以降、suspend して resume したら LCD の明るさが最大になってしまい変更できなくなってしまったんですね。
10.1-RELEASE までだと Fn7,8 などで明るさが変更できた。 acpi_ibm や acpi_video がなくとも変更ができた。しかし、10.2-RELEASE 以降では Fn7,8 ボタンが効かなくなって、acpi_ibm の dev.acpi_ibm.0.lcd_brightness も有効にならなくて acpi_viode の hw.acpi.video.lcd0.brightness も使えなくなった。
resume 後に明るさを変えることができなくなったので、僕はいつまでもカーネルは 10.1-RELEASE を使い続けている。と、いうことです。

あと、別の手段としては ports から sysutils/acpi_call/ をインストールして ACPI のパラメータを表示したり変更したりできるようですが \_SB_.PCI0.VGA.LCD._BCM なパラメータなどをいじったりするなど、ちょっと試してみましたがダメでした。

acpi_call のコマンドイメージをちょっと書いておきます。使うには kldload acpi_call.ko する必要があります。

# acpi_call -vp '\_SB_.PCI0.VGA.LCD._BCM' -o i -i 50
Path: \_SB_.PCI0.VGA.LCD._BCM
Number of arguments: 1
Argument 1 type: Integer
Argument 1 value: 50
Status: 0
Result: 1

 
acpidump -d の結果を確認すると _BCM ってのが “Brightness Control Method” らしいです。他にも _BCL ってのがあって、こいつは “Brightness Control Levels” らしいです。
acpi_call で _BCM の値を 50 に変更してあげる。ってのが上記のコマンドと、その結果です。
しかし、値は反映されない・・。 orz

 
ThinkPad でも Nvidia のグラフィックスカードを利用しているヤツは Nvidia のツールで画面の明るさを変えられたり Intel の場合は graphics/intel-backlight/ などで画面の明るさを変えられるらしいです。
僕の ThinkPad e145 は Radeon のチップなので・・。orz

多分 10.2-RELEASE 以降で ACPI 周りに変更が入ったのでしょうなぁ。

ThinkPad e145 は BIOS モードと UEFI モードの両方で 11.0-RELEASE で試しましたが画面の明るさは変えることができませんでした・・。

と、いうことでももうしばらく、ってか、壊れるまで？ 10.1-RELEASE の利用は続きそうです・・。