8月 072019
 

最近の FreeBSD は BIOS では PC の機能が使えなくなってきているものがちらほら出てきて、いよいよ UEFI に変えるべきかと思えてきた。
僕の持っているちょっと古いが、今でも現役の ThinkPad E145 を BIOS で利用するのは FreeBSD/amd64 10.1-RELEASE が一番良かった。その後 10.3-R -> 11.2-R にしてみると LCD の明るさが変えられなくなったりとか。
最近 11.3-R にしたら suspend して resume すると /dev/psm0 が『もう使えないよ。』みたいなエラーを吐きやがる。

psm0: failed to get status (doinitialize).
psm0: failed to enable the device (doopen).
psm0: failed to enable the device (reinitialize).

 
こんな感じ。 resume 後はもう USB なマウスを使うしか手がない。 /dev/psm0 だけでなく /dev/sysmouse (こっちはタッチパッド) も使えない状態。 moused も hald も悲しい状態。

/dev/psm0 みたいなのは BIOS べったりなので OS 的に UEFI 対応が進む FreeBSD ではいよいよ使えなくなってきているのだろうなぁ。などと、思い、それじゃ。と、いうことで UEFI で起動してみるかぁ。と、なったのであります。

 
以前、このブログでは ThinkPad E145 を BIOS+MBR の組み合わせで Windows8 と FreeBSD のマルチブートについてエントリを書いているのですが、今回はいよいよ UEFI+GPT でのブートになります。
当時 (上記 URL の記事は 2013 年 09 月に書いていますね) は、マルチブートに関する前例が中々見当たらず、インターネット上にもそれらしい記事がなかったのですが、最近は探せばちらほらと見つかるようになってきましたね。それは非常に良いことです。

と、いうことで僕もトライ。今回は、自分の今後のことも兼ねて、メモ的にその手順について書き留めておきます。まぁ、作業はほとんどが Windows10 上で行うんですけどね。

おおまかな手順は以下です。

0. Windows の回復 USB メモリの作成
1. Windows10 をまずインストール。もしくはパーティションを分割
2. FreeBSD 用 EFI パーティションを作成
3. FreeBSD/amd64 12.0-RELEASE をインストール
4. bcdedit でマルチブート設定
5. EFI パーティションにファイル設置
6. 電源投入で FreeBSD 起動

だいたいこんな感じでしょうか。では、はじまりです。

一応、断っておきますが、0 番目の「回復 USB メモリ」はもしものためにちゃんと作成しておきましょう。僕は Windows10 環境を何回もぶっ飛ばしていたりしますが、もし、そうなっても僕は責任持てません:-|。

 
1. Windows10 のインストール
新しい PC を買ってきたときや、今使っている PC には Windows10 が最初から入っていると思われます。
コントロールパネル -> コンピュータの管理 -> ディスクの管理 で、Windows10 に割り当てられているパーティションをちっこくしてあげる。詳細は書きませんけども。
新規に Windows10 をインストールする場合は C:\ を好きなサイズにして FreeBSD をインストールするスペースを残しておきます。
まず最初に Windows10 をインストールする。もしくは Windows10 がインストールされている状態。と、いうのが重要です。

 
新規に Windows10 をインストールする場合、ブート用の USB メモリを作成するところから始める人がいるかもしれませんが、僕の場合、今回は Windows のアプリで rufus と、いうのを利用しました。

バージョンにもよるかもしれませんが、 Windows10 の ISO ファイルは rufus に食わせると USB の起動イメージを BIOS+MBR で作るか UEFI+GPT で作るか指定できます。もしこの時に UEFI+GPT で作成した場合には NotePC の BIOS 設定は UEFI モードにしないとイントールできません。
Widowos10 の USB の起動イメージを BIOS+MBR で作ると、インストールした Windows10 は BIOS+MBR になってしまいます。今回は UEFI+GPT で USB 起動イメージを作成することになります。

作成した USB 起動イメージに合わせるために BIOS の設定を確認しましょう。 BIOS の設定については以前書いています。そちらを参考にしてください。

さてと。これで Windows10 のインストールが無事に完了しました。

 
2. FreeBSD 用 EFI 領域の確保
FreeBSD を ISO イメージから起動してメニューの [install] を選択して進めていくと、 Windows10 がインストールされているにも関わらず FreeBSD しかブートしない NotePC になってしまいます。 bsdinstall を利用して (それはつまりは FreeBSD をフツーにインストールする。と、いうことです) FreeBSD をインストールすると既に存在する Windows10 の EFI パーティションを上書きしてしまうからなんですね。

フツーの人 (それは takawata さん みたいにマニアではない人のこと;-) は FreeBSD はフツーにインストールすると思います。

しかし、フツーにインストールすると既にある EFI パーティションを上書きして潰してしまうので、新規に 100MB 程 EFI パーティションを作成してあげます。

Windows10 は既に起動しているはずなので、以下のコマンドを管理者権限の DOS プロンプトから実行します。

c:\ diskpart
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list part
DISKPART> 
DISKPART> create partition efi size=100
DISKPART> format quick fs=fat32 label="FreeBSD-EFI"
DISKPART> assign letter="S"
DISKPART> 
DISKPART> list vol
DISKPART> list part
DISKPART> exit

 
簡単にコマンドイメージだけ書きました。

1). diskpart.exe を管理者権限で実行
2). 対象とするディスク番号を選択
3). ディスクのパーティション状況を確認
4). いよいよ create partition で EFI パーティションを 100MB で作成
5). fat32 でフォーマットして、ラベルは FreeBSD-EFI とする (お好きな文字列をどうぞ)
6). assign letter=”S” でおまじない;-)

 
これで FreeBSD の bsdinstall がアクセスする EFI パーティションが作成できました。 FreeBSD を何回インストールしても、インストール後に NotePC を再起動すると Windows10 が起動する状態になります。

上記 takawata さん の URL ではこの工程がないので Windows 側の EFI パーティションを守るために bsdinstall を利用しないで make buildworld しているんですね。あ。 takawata さんは『マニア』なのかもしれないですが、 make buildworld が好きな人なのですね。きっと;-)。

それにしても bsdinstall が既存の EFI パーティションを上書きしてしまうのが問題なんですね。メニューで上書きするかしないか選択できるようにすれば良いのに・・。

と、いうことで次は FreeBSD のインストールです。

 
3. FreeBSD のインストール
今回は FreeBSD-12.0-RELEASE-amd64-bootonly.iso をチョイスしました。もう、面倒なので Windows10 上で、やはり rufus を使い USB 起動イメージを作成しました。
FreeBSD の場合は、今度は BIOS+MBR でしか作成できません。なので、FreeBSD インストール時には今度は BIOS の設定を Legacy モードにする必要があります。

あとはフツーにインストール。パーティション分割のところで GPT を選択し、更に [Manual] を選択してHDD (最近は SSD か;-) の空き領域にインストールします。

インストールが完了してリブートします。 2. のところで書いた通り、先に FreeBSD 用 EFI パーティションを作成していると bsdinstall を利用しても Windows10 側の EFI パーティションはつぶれてないので、この時点で再起動後は Widnows10 が起動するはずです。
もし FreeBSD が起動してしまった場合は Windows10 がつぶれてしまった。と、いうことです。回復 USB メモリなどから Windows10 を復旧しましょう。

 
4. bcdedit でマルチブート設定
FreeBSD インストール後に再起動したら Windows10 が起動しましたが、インストールした FreeBSD はしっかり残っております。起動させるために Windows10 側で bcdedit を利用してエントリを作成してあげます。

以前、このブログでも BIOS+MBR 環境のときに bcdedit を利用して、Windows Boot Manager から Windows と FreeBSD をブートしていましたが、 UEFI+GPT の場合は Windows Boot Manager が利用できません。 UEFI+GPT でのマルチブート環境は Firmware Windows Boot Manager を利用してブートすることになります。

そもそも「Firmware Windows Boot Manager」とはなんぞや?と、なるのですが、簡単に言うと BIOS(UEFI) のブートセレクタです。
例えば HDD からブートするとか、CD や USB メモリからブートするとか、選択する画面は Fn キーを押してメニューを出しますが、それをどうやら「Firmware Windows Boot Manager」というようです。
CD や USB・HDD からブートするのと同じレベルのメニューに “FreeBSD” や “Windows Boot Manager” メニューが存在している状態になります。

ThunkPad の場合 (Lenovo の PC の場合) は電源投入時に F12 キーを押すとブートセレクタが現れます。メーカによっては F2 キーだったり F8 キーだったりするかもしれません。

これから、このブートセレクタに bcdedit でメニューを登録していきます。

 
まず、管理者権限の DOS プロンプトでフツーに bcdedit と叩くと「Windows Boot Manager」のメニュー画面の情報が出力されます。僕の知っていた bcdedit はこの、オプションなし状態の出力でした。

「Firmware Windows Boot Manager」の項目を表示するには以下のコマンドを打ちます。

C:\Windows\system32> bcdedit
C:\Windows\system32> 
C:\Windows\system32> bcdedit /enum firmware
C:\Windows\system32> bcdedit /enum all

 
/enum オプションをつけて、そのあとに firmware とすると「Firmware Windows Boot Manager」の項目を表示します。 all と打つと「Firmware Windows Boot Manager」と「Windows Boot Manager」の全ての項目を表示します。ここ、重要ですからね;-)。

まず、「Firmware Windows Boot Manager」に FreeBSD のメニューを追加します。

C:\Windows\system32> bcdedit /copy "{bootmgr}" /d "FreeBSD"
*** ここで UUID が表示される ***
C:\Windows\system32> bcdedit /set {UUID} device partition=\Device\HarddiskVolume2
C:\Windows\system32> bcdedit /set {UUID} path \EFI\FreeBSD\Boot\bootx64.efi
C:\Windows\system32> bcdedit /set fwbootmgr displayorder {UUID} /addfirst

 
以下のような雰囲気です。

1). /copy で “FreeBSD” というエントリを作成。このときに FreeBSD の UUID が割り当てられる
2). エントリ中に device を設定 (省略可)
3). エントリ中に path を設定
4). エントリ中の順番を設定

最後の 4). のエントリについて先に説明します。 /addlast で最後に追加することもできます。その場合 F12 キーを押さない場合は Windows10 が起動します。 /addfirst を指定すると先頭に追加され、 F12 キーを押さない場合は FreeBSD がブートするようになります。お好みで;-)。

上記コマンドを投入したあと、再度 bcdedit /enum firmware を叩いてみましょう。以下は抜粋です。

C:\Windows\system32> bcdedit /enum firmware

ファームウェアのブート マネージャー
--------------------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {dd655fef-3160-11e9-8f42-a6c75caf7b54} <- 先頭に追加
                        {dd655fe9-3160-11e9-8f42-a6c75caf7b54}
                        {dd655fea-3160-11e9-8f42-a6c75caf7b54}
timeout                 2
<--- 略 --->
Windows ブート マネージャー                                       <- 今回追加
--------------------------------
identifier              {dd655fef-3160-11e9-8f42-a6c75caf7b54}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\FreeBSD\Boot\bootx64.efi
description             FreeBSD
locale                  ja-JP
inherit                 {globalsettings}
badmemoryaccess         Yes
default                 {current}
resumeobject            {dd655fed-3160-11e9-8f42-a6c75caf7b54}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30
<--- 略 --->

 
このあとに説明しますが、UEFI+GPT の場合、OS をブートさせるためには EFI パーティションにファイルを一個置いてあげる必要があります。FreeBSD の場合は、インストールされている FreeBSD の /boot/boot1.efi を上記エントリの device と path に指定したところに正しく置いてあげる必要があります。

記載内容を間違えると「Firmware Windows Boot Manager」で “FreeBSD” を選択しても何もアクションが起きません。

そして、この内容が、BIOS+MBR の頃のように

device                  partition=c:\
path                    \bootx64.efi

 
などと記載していると「Windows Boot Manager」側で認識して、ブートすると 0x000007d みたいなエラーが出力されます。

記載した内容と設置した場所を正しく一致させましょう。

 
ちなみに作成したエントリを消す bcdedit は以下になります。書いては消して、また書いて、ブートしないのでまた書いて・・。などと、いうとき用です;-)。

C:\Windows\system32> bcdedit /delete {UUID} /f
C:\Windows\system32> bcdedit /set {fwbootmgr} displayorder {UUID} /remove

 
一行目は bcdedit /copy “{bootmgr}” で作成したエントリ全てを消すコマンドです。このコマンドを実行すると「ファームウェアのブートマネージャー」からも削除されます。
二行目のコマンドは「ファームウェアのブートマネージャー」から削除するときのみ利用するコマンドです。例えば /addlast で一番最後に登録したけど、やっぱり /addfirst で先頭に登録したい。などとうとき、二行目のコマンドを実行したあとに再度 bcdedit /set fwbootmgr displayorder を叩く。と、いうときに利用します。

bcdedit で「Firmware Windows Boot Manager」に登録するコマンドはこんな感じでしょうか。

 
5. EFI パーティションにファイル設置
さてと。あと少しで環境が整います。 EFI パーティションに FreeBSD がブートするための boot1.efi を書き込んで上げます。他の PC 上で動作している FreeBSD から /boot/boot1.efi を持ってきて Windows10 側に保存して上げましょう。

まず、diskpart.exe でボリュームの確認です。

c:\ diskpart
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list vol
  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0         回復           NTFS   Partition    499 MB  正常
  Volume 1     C                NTFS   Partition    213 GB  正常         ブート
  Volume 2                      NTFS   Partition    574 MB  正常
  Volume 3                      FAT32  Partition    100 MB  正常         システム
  Volume 4         FREEBSD-EFI  FAT32  Partition    100 MB  正常         非表示
DISKPART>

 
EFI バーティションは Windows10 が作成したもの (Volume3) と FreeBSD インストール時に作成したもの (Volume4) と二つありますが、どっちを利用しても問題ありません。

Windows10 で EFI パーティションをマウントするためには以下のコマンドを利用します。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> mountvol z: /D
C:\Windows\system32> mountvol z: \\?\Volume{874c2b19-1ada-4089-9a27-de7f61f38177}\
C:\Windows\system32> mountvol z: /D

 
mountvol.exe コマンドですが、オプションなしで実行するとヘルプと、下のほうにボリュームの一覧が表示されます。
Windows10 が作成した EFI パーティションを z:\ に mount する場合には二行目のコマンドを打ちます。
FreeBSD のインストール時に作成した EFI パーティションをマウントするには四行目のコマンドを利用します。 mountvol のオプションなしで実行した場合に下のほうに「現在のマウント ポイントとボリューム名の考えられる値:」で表示されたマウントポイントの *どれか* を指定します。
diskpart.exe の list vol や list part と見比べてじっくりと判断してください;-)。

ちなみに mountvol z: /D はumount するオプションです。

 
今回は FreeBSD インストール時に作成した EFI パーティションは利用せず、Widnows10 側の EFI パーティションを利用します。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> z:\
z:\> mkdir EFI\FreeBSD\Boot 
z:\> cd EFI\FreeBSD\Boot 
z:\> copy c:\boot1.efi ./bootx64.efi
z:\> dir
z:\> c:\
C:\Windows\system32> exit

 
mountvol で Widnows10 の EFI パーティションを z: に mount します。 z:\ に行くと既に EFI というディレクトリが掘られています。そこに FreeBSD 用のディレクトリを作成し、c:\ に置いた boot1.efi という FreeBSD から引っこ抜いてきたファイルを bootx64.efi として保存します。
途中、ls ではなく dir コマンドで色々確認しつつ作業を行ってください。 設置場所は bcdedit コマンドで指定した device と path の各オプションと一致していることが重要です。

ちなみに mountvol で EFI パーティションをマウントしていると bcdedit /enum firmware で確認した場合の device パラメータの表示が変わってきます。 mountvol で mount している状態のほうが確認しやすいです。

 
さてと。これで全ての準備が整いました。Windows10 側でリブートしましょう。 /addfirst を指定した場合は NotePC 再起動後にスルスルっと FreeBSD が起動するようになります。

やったっ!!

もし FreeBSD が起動しなかった場合は bootx64.efi の設置場所が bcdedit で指定したものと合っているかじっくりと確認してください。

僕の場合ですが、大失敗・・。 copy c:\boot1.efi ./bootx64efi とやっていました・・。orz
これじゃ起動しません。rename bootx64efi bootx64.efi として事なきを得、無事に FreeBSD が起動したのでありました。ふぅ。そして、パチパチパチ。

 
6. 電源投入で FreeBSD 起動
さてと。僕の場合 ThinkPad E145 は FreeBSD メインで利用し、時々 Windows10 を利用する形態なので bcdedit /set fwbootmgr displayorder {UUID} /addfirsst で登録しました。これだと電源投入後はサクっと FreeBSD が起動します。

Windows10 を起動したいときには NotePC の電源投入後に F12 キーを押してブートセレクタを表示して「Windows Boot Manager」を選択すると Windows10 が起動するようになります。

 
さてと。最後に FreeBSD 12.0-RELEASE についてちょっと書いておきます。

今まで僕はずっと BIOS+MBR な FreeBSD しか使ったことがなかったのですが、今回初めて UEFI+GPT な FreeBSD を使うことになります。
一番上で書いた /dev/psm0 が resume 後に psm0: failed to get status となって使えなくなった事象は解決しました。やっぱり FreeBSD の ACPI 周りはどんどん UEFI に傾倒して行っているのね。と、再確認できました。

あと、ThunkPad E145 など AMD のグラフィックスチップ使っている PC 限定かもしれませんが、グラフィックスチップは graphics/drm-fbsd12.0-kmod で認識しています。今までは radeonkms.ko を指定していましたが、これを利用するとカーネルパニック頻発です。 amdgpu にしたら安定しました。 UEFI ブートとは相性が良くないみたいですね。 pkg-message にも書かれています。

しかし、 UEFI にしても acpi_video.ko が使えない状態なのは変わらず。なので、ディスプレーの明るさは変えられません。 AMD グラフィックスチップの悲劇か・・。

 
とまぁ、ツラツラと書いてみましたが UEFI+GPT にした PC において Windows と FreeBSD のマルチブートについて書いてみましたが、大きな点としては

1). bsdinstall は Windows 側の EFI パーティションを潰してしまう
2). 「Windows Boot Manager」ではなく「Firmware Windows Boot Manager」でマルチブートを実現

でしょうかね。

1). のほうは僕も過去に実はずいぶんとハマりました。どうして Windows10 が起動しないのだっ!!?? みたいな・・。知っている人はちらほらいるみたいですが、僕は Slack のとあるコミュニティで FreeBSD のエラい人に教えてもらいました。 FreeBSD のインストールのために EFI パーティションを一個作成する。ってことがミソですね。

ちなみにですが、/boot/boot1.efifat が、ここで書いてきた FreeBSD インストール前に作成した EFI パーティションの中身です。
bsdinstall が Windows10 側の EFI パーティションを boot1.efifat で上書きしています。 FreeBSD インストール前に EFI パーティションを作成すると bsdinstall は FreeBSD インストール前に作成した EFI パーティションに対して /boot/boot1.efifat が書き込まれ Windows10 側の EFI パーティションは無傷です。

mountvol z: \?\hoge\ で FreeBSD 側 EFI パーティションも mount できるので確認してみるのも良いかも。

2). のほうはある意味目ウロコですね。 Windows Boot Manager を捨ててその一個前のフェーズで FreeBSD をブートしてしまう。 grub とか、他のブートマネージャは不要で bcdedit でなんとかしてしまう。ってことになりますね。

FreeBSD インストール前に EFI パーティションを一個作って、 bcdedit /enum firmware のコマンド群で制御。

この二つが今回は大きな収穫でした。これで UEFI な PC でもマルチブートは大丈夫っ!! 新しい NotePC 買おうかなー;-)。

9月 092018
 

僕が利用している ThinkPad E145 はカーネルがずっと 10.1-RELEASE のままで、ユーザランドが 10.4-RELEASE だったりしていました。これは以前にも書いていますが suspend/resume が動作しなくなる。resume 後にバックライトの調整ができなくなるため、しかた無く。の対応だったんですね。

あと、ThinkPad E145 はグラフィックスカードに Radeon HD 8330 を利用していて、このチップは radeonkms.ko では未対応で Xorg のドライバでは VESA を利用していたんですね。

そして、 KDE5 は 10.4-RELEASE でコンパイルしたものは、コンパイルしたバージョンとは違う 10.1-RELEASE 上では動作しない。と、いうことになり、そろそろ新しい NotePC を買うことを考えていたところに drm-next-kmod がバリバリと動作する。 Radeon HD 8330 も radeonkms.ko で動作するようだ。と、いうので 10.1-RELEASE から 11.2-RELEASE にいっきに上げてみることにしました。

と、ここまでが前振りです(^^;;。
freebsd-update でいっきに 11.2-RELEASE にして pkg delete -a で古い packages を削除したあとに 11.2-RELEASE でコンパイルした KDE5 一式をドドドとインストール。その他 NotePC に必要なモノをインストールします。

そして、今回はそこに graphics/drm-next-kmod をインストールします。 /usr/ports/graphics/ の下を見ると、全部で以下があるようです。

・drm-devel-kmod/
・drm-legacy-kmod/
・drm-next-kmod/
・drm-stable-kmod/

まぁ、見て、雰囲気が大体解ると思われますが;-)。

graphics/drm-next-kmod をインストールすると /boot/modules/ の中がずいぶんとにぎやかになります。

この中から radeonkms.ko を見つけ出してブート時に kldload するように、/etc/rc.conf に設定します。

# --- kernel module load --- #
kld_list="/boot/modules/radeonkms.ko"

 
radeonkms.ko は今回 graphics/drm-next-kmod でインストールしたモノと別にシステム標準の /boot/kernel/radeonkms.ko があります。 /boot/loader.conf に radeonkms_load=”YES” と書くとシステム標準のカーネルモジュールがロードされてしまうため、上記のように記載します。

インストールが完了したあとは /etc/X11/Xorg.conf を編集してあげます。最近は /usr/local/etc/X11/xorg.conf.d/ 内にドライバ・キーボード・マウスなど、個別のファイルを用意して /etc/X11/Xorg.conf は書かない。ってのが流行みたいですねぇ。まぁ、どっちにしろ Section “Device” の項を書き換えます。

Section "Device"
        Option      "TwinView" "true"
        Option      "TwinViewOrientation" "LeftOf"
#       Option      "RegistryDwords" "EnableBrightnessControl=1"
        Identifier  "Card0"
#       Driver      "radeon"
#       Driver      "vesa"
        Driver      "modesetting"
        BusID       "PCI:0:1:0"
EndSection

 
Driver radeon は動作しないので、しょーがない。今までは Driver vesa で使っていたのですが、今回 graphics/drm-next-kmod にしたので Driver modesetting にしました。最近の Xorg は賢くなって色々なモノを自動認識するようになり、デバイスにあったカーネルモジュールをロードしてくれるようです。

と、いうことで上記の設定ができたらリブートしましょう。
リブート後、僕の ThinkPad E145 では以下のカーネルモジュールがロードされるようになりました。 linuxkpi.ko が今回のカナメでしょうかねぇ。

--- <上略> ---
23    1 0xffffffff82421000 15d6d9   radeonkms.ko
24    1 0xffffffff8257f000 74b70    drm.ko
25    4 0xffffffff825f4000 edc8     linuxkpi.ko
26    3 0xffffffff82603000 114b8    linuxkpi_gplv2.ko
27    2 0xffffffff82615000 6b8      debugfs.ko
28    1 0xffffffff82616000 23f8     radeon_kabini_pfp_bin.ko
29    1 0xffffffff82619000 23f8     radeon_kabini_me_bin.ko
30    1 0xffffffff8261c000 23f8     radeon_kabini_ce_bin.ko
31    1 0xffffffff8261f000 43f8     radeon_kabini_mec_bin.ko
32    1 0xffffffff82624000 2a78     radeon_kabini_rlc_bin.ko
33    1 0xffffffff82627000 12e8     radeon_kabini_sdma_bin.ko
34    1 0xffffffff82629000 38eb0    radeon_bonaire_uvd_bin.ko
35    1 0xffffffff82662000 13328    radeon_BONAIRE_vce_bin.ko
36    1 0xffffffff82676000 37528    linux.ko
37    2 0xffffffff826ae000 2d28     linux_common.ko
38    1 0xffffffff826b1000 31e50    linux64.ko
--- <以下略> ---

 
Xorg を起動し、ログインマネージャの x11/sddm を起動し KDE5 にログインします。そして、 「KDE システム設定」から[ディスプレイとモニタ]->[Compositor]ときて、[レンダリングバックエンド]を確認します。VESA ドライバを利用していたときは選択できるのは xdandr のみだったのですが、今は OpenGL2.0 や 3.1 が指定できます。おぉっ!! これで 「ゆれるウインド」とか「魔法のランプ」などが利用できるようになるっ!!

ってんで、 graphics/drm-next-kmod の恩恵が受けられるのでありました。

 
で、次のステップですが、 まだ、以下の二点が残っております。

・suspend/resume はちゃんと動くの?
・バックライトの明るさ調整はできるの?

まず、suspend/resume についてですが、最初の 1,2 回はフタを閉じた段階でシステムごとフリーズしていたので『むむむ。 graphics/drm-next-kmod は suspend/resume に対応してないのか?』などと思ったのですが、ロードするカーネルモジュールとかその他設定を見直すことで無事に suspend/redume が動作するようになりました。

ThinkPad E145 では acpi_video.ko はまともに動作してないので利用していません。 acpi_ibm.ko はバックライト調整はできないけどボリューム調整はできるのでロードしています。

 
次にバックライト問題ですが、これは、本家でも wiki の掲載があるほどなので、ことは一大事なのでしょうなぁ。

https://wiki.freebsd.org/Graphics/Brightness

ここに書いているのは一通り試しました。上にも書いた通り ThinkPad E145 は Radeon HD 8330 なので intel_backlight (ports 的には graphics/intel-backlight) を使うと Device not found. です。あら。つべたい。

accessibility/sct はオプションの数値を変えると色が変わるので、 LCD brightness とはちょっと違う。

で、結局、僕は xrandr を使うことにしました。xrandr は VESA ドライバを利用している頃はまともに動作しなかった (Can’t open display と表示される) のですが、 graphics/drm-next-kmod を使うと無事に動作するようになりました。

まず、以下のコマンドを打ってディスプレー名を取得します。

$ xrandr --listmonitors
Monitors: 1
 0: +*LVDS-1 1366/256x768/144+0+0  LVDS-1

 
最後の LVDS-1 が重要で VESA ドライバを利用していた頃はこの値が表示されず xrandr で明るさの調整ができなかったんですね。今回 graphics/drm-next-kmod を利用することによりちゃんと動作するようになりました。ここまで来ればラクショーです。あとは以下のようにコマンドを打って画面の明るさ調整をすれば良いだけ。

$ xrandr --output LVDS-1 --brightness 0.8

 
今動作している明るさが 1 で、それよりも暗くしたい場合は 1 以下の数値を小数点で指定し、更に明るくしたい場合は 1.2 とか指定すれば良いです。

雰囲気的には機械的にバックライトを調整するのではなく、画面の色をグレーにすることで暗くなったように見える。と、いう機能ですね。ハードウェア的にバックライトを暗くしてないのでバッテリー運用のときは要注意って感じでしょうか。

 
と、いうことで CPU/GPU 共に AMD な NotePC である ThinkPad E145 ですが、

・11.2-RELEASE にした
・graphics/drm-next-kmod で Radeon HD 8330 を認識してくれる
・KDE5 が使えるぞぉ (これは当たり前;-)
・suspend/resume ができる
・バックライト調整も一応できる

と、いう状態になり、ほぼほぼ満足な結果です。細かく言うと

・キーボードが 101 のままだぁ
・マウスの動作があやすぃー
・音の出るところ調整(スピーカーかイヤホンか)

など、ありますが、それらは Xorg の設定で調整するもヨシ。KDE5 側で設定するもヨシ。と、いう状態なので、道は色々あります。それらを一応全て解決できたので、僕の ThinkPad E145 は壊れなければあと 4,5 年は持つような気がしてきました;-)。

3月 112017
 

僕が持っている 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 の利用は続きそうです・・。

11月 182013
 

連チャンで ThinkPad e145 のネタですみません。 FreeBSD ネタはこれが最後です。無事に suspend/resume ができることを確認しました。

前回のエントリ「FreeBSD で suspend/resume するかの確認方法。
前々回のエントリ「ThinkPad Edge e145 で利用する FreeBSD。

上記二つのエントリで「あれ? suspend/resume が動かないなぁ。」とか思っていたのですが、色々見なおしたら無事に動作するようになりました。見なおした点は以下の通り。

・カスタムカーネル
・/boot/loader.conf
・/etc/sysctl.conf

カスタムカーネルと /boot/loader.conf はまぁ、ほぼ連動しているという気がするのですが、それ以外にも /etc/sysctl.conf を見直しました。これらの設定は 9.2-RELEASE が動作していた Thinkpad X100e から引き継いだ情報だったのですが、同じ設定内容では e145 は suspend/resume しない。と、いうことですね。

上記三つのファイルを以下の URL に置いておくのでもし良かったら参照してみてください。

カスタムカーネルコンフィグ
/etc/loader.conf
/etc/sysctl.conf

色々なファイルを消したり書いたり、色々なパラメータを追加したり削除したりを繰り返したのですが、上記の設定で安定して suspend/resume するようになりました。カーネルモジュールのロードではなく kenv などの設定のほうだと思っているんですけども。
実際に的確に原因を特定したわけではありませんが、僕的には hw.pci.enable_io_modes などが怪しいのかなぁ? とか思ったりもしたのですが、本当に特定はできていません。

 
resume から返って来た FreeBSD ですが、比較的簡単な問題点が二点。

・サスペンド時には X 上で動作していたマウスがレジューム後には動作しなくなります。/etc/rc.resume 内で /etc/rc.d/moused restart すれば良いでしょう。
・レジューム後に画面がやたらと明るくなってしまいます。 Fn+F7 で暗くしてあげてください。
・KDE4 を利用している人は「電源の管理」にサスペンドの情報が渡らなくなりました。 KDE4 側で自動休止とかできなくなったのがちょっと悲しいかな。

いじょ;-)。

と、いうことでこれで FreeBSD をバリバリ利用できる NotePC になりました。新製品で出たばかりの ThinkPad Edge e145 ですが、無線 LAN とか SD Card Reader とか動かない機器もありますが、まぁ、ヨシとしておきましょう。グラフィックスは vesa ですけど、驚くほど速く動作します;-)。

僕的には X100e に続いて中々使える NotePC。 になりそうです。

11月 122013
 

いやー。前回のエントリでは Windows と FreeBSD がなんとかマルチブートできる環境が構築できた。というエントリでしたが、ここでは実際に freeBSD を利用してみた感想を書いてみたいと思います。

 
1. OS のチョイス
今回は UEFI+GPT に対応していない FreeBSD/amd64 9.2-RELEASE をチョイスしました。インストール方法は前回のエントリに書いているのでそっちを参照してください。

本当は FreeBSD/amd64 10.0-BETA3 でも良かったのですが、僕の環境で利用している FreeBSD はほぼ全てが /amd64 9.2-RELEASE なんですね。何が良いかと言われれば pkgng の恩恵をごっそりと受け継げることができる。と、いうことですね;-)。

まず先に pkgng のことをちょっと書いておきましょうかね;-)。

デスクトップ PC で稼働している FreeBSD を pkgng 化して packages をドドドと作成します。2,3 の設定は以下の通り。

・/usr/ports/ports-mgmt/pkg をインストール
インストール後は pkg2ng を実行しろ。というので実行します。まぁ、新規インストールな状態なのでサクっと終わりますが;-)。

・/etc/make.conf に以下の行を追加
ここいらの設定はあちこちに書いてありますね。

WITH_PKGNG=yes

 
・packages の作成
そもそも KDE4 などの統合デスクトップ環境をインストールすると 800 個近い packages がインストールされています。インストールされたこれらを package 化します。以下はそのスクリプトです。

#!/bin/sh
pkg info | grep $1 | awk '{print "pkg create -f tbz -n -g -o /usr/ports/packages/All " $1}' | sh -x

 
一行野郎ですが、これを例えば pkg-create.sh という名で保存し、実行時には ./pkg-create.sh kde などとオプションを指定すると kde と付いた pkg info で表示される全てが packages 化されて /usr/ports/packages/All/ に格納されます。
ただ、関連性のあるプログラムまでは packages 化してくれないのであとからチマチマこのコマンドを実行する必要があるかもです;-)。

 
・packages のインストール
新しくインストールした ThinkPad e145 上の FreeBSD は同じく pkgng 化したあとに NFS でマウントした /usr/ports/packages/All/ に cd して、そこで pkg add kde* などと打つとドドドとインストールしてくれます;-)。

ただ、この pkg add するためには設定ファイルを一個用意して置く必要があります。
/usr/local/etc/pkg.conf というファイルを一個用意してあげます。

# cd /usr/local/etc
# echo "packagesite: http://pkg.freebsd.org/${ABI}/latest" > pkg.config

 
/usr/local/etc/pkg.conf.sample と、いうファイルがありますが、とりあえず一行だけ書いたファイルを置いてあげると pkg add が動き出します。このファイルが無いと pkg add はスルっと終わってしまい packages をインストールしてくれません。
packages 自体はこのファイルに書いたホスト名など、リモートから取って来なくてカレントデイレクトリの packages を利用したいので、これで十分です;-)。

以上で新規にインストールした FreeBSD の環境が整いました。早いです;-)。

 
2. 動くデバイスと動かないデバイス
packages がドドド入ったので X を起動したり色々やる準備が整いました。で、まず、動かないもの(デバイス)を書きましょうか。

・Wi-Fi: Broadcom (多分 BCM943142HM)
・Bluetooth: Broadcom 製 USB 経由 で 4.0 対応
・SD Card Reader: Realtek 製

これらはダメですね。 FreeBSD 側にドライバが無いようです。あと、渋いところでいうと AMD の SUBus が認識しない。この辺りについては pciconf -lv を置いておきますのでそちらを参照して頂ければと思います。

続いて X ですが、 e145 の CPU というか APU は A4-5000 で Radeon HD 8330 な GPU ですが、以下の URL で確認すると・・。

https://wiki.freebsd.org/AMD_GPU
https://wiki.freebsd.org/Graphics

と、いうことで Radeon HD 8000 番台は “Not supported” だそうです。残念ながら VESA 決定ですね。最後に要らないとは思うけど、xorg.conf を付けておきます。
タッチパット・トラックポイント共に動作する設定が入っています。

 
動くもので気がついたのを書いてみます。

・suspend/resume する (あれ?しなくなった。ちょっち調査中)
・テンキーで画面の明るさ変更が可能
・音は出る
・USB カメラは webcamd+cuse4bsd+pwcview で動きます

くらいかな?

 
試してないものは以下の通りですが、これは多分 Xorg とか KDE4 の機能に引っ張られると思うなぁ。あとで確認してみよう。

・D-SUB 15pin/HDMI/LCD があるけど、三画面出力とか可能なのかな?
・バッテリーの持ち状況とかまだ確認してないです

あと、以前の「PRIMERGY MX130 S2 を FreeBSD で利用する。」というエントリで「hwpstate0: set freq failed, err 6」というメッセージが延々と出力される。と書いたことが有りましたが、この NotePC でもやはり表示されます。回避策は上記エントリに書いてあるのでそのパッチを適用しました。

 
実際に ThinkPad Edge e145 を FreeBSD で利用してみた体感的な感想をちょっと書きます。比較は ThinkPad X100e とですが、実測値とかなくてすみません。

・CPU は 2Core から 4Core になったので余裕を感じます。あと、 CPU の温度が低いですね。ファンが唸りを上げて回るというのはまだ体験していません。その点からするとたとえ遅くとも「良いんじゃね;-)。」と思えます。
・Xorg が VESA でしか利用できないのが痛いかなぁ。とか思ったのですが、最近の VESA は以前よりも進んでいますね。以前は 1024×768 を 1366×768 横方向に拡張して表示してくれていたのですが、今の VESA はちゃんと画面のサイズでで表示してくれます。 2D のみなら VESA でも我慢できるかなぁ。と、いう感じかな。

しかし、KDE4 の「デスクトップ効果」では xrandr を利用してウィンドの透明化とか全仮想デスクトップの表示とかが動きます。あれあれ? VESA でも今は十分に動いているよ。状態です。 ThinkPad X100e の頃の VESA とは随分と違い驚いています;-)。

 
とまぁ、こんな感じですが、これは続くかどうかわかりません;-)。

ThinkPad X100e の場合は枯れた技術を利用した新製品の NotePC でしたが、今回購入した e145 は最新鋭の NotePC になるので X100e の頃よりは色々と楽しめそうです;-)。

と、いうことで ThinkPad Edge e145 で FreeBSD/amd64 9.2-RELEASE をインストールして動作している状態の情報を提示します。

起動時の dmesg
pciconf -lv の結果
sysctl -a の結果
vesa だけど xorg.conf

皆さんも是非 FreeBSD を PC ネーテブで動かしてみてください;-)。

9月 102012
 

普段から利用している ThinkPad X100e ですが、こいつは Windows7 と FreeBSD/amd64 9.0-STABLE のマルチブートで利用していました。ところが、 FreeBSD 側で利用していたら GEOM がエラーを吐き出すようになってきて、どうやら HDD がご臨終のようです。
シングルユーザでブートして fsck -y を走らせても完走しないしないので、いよいよ HDD を交換することにしました。
#この前の段階でバックアップは既にバッチリ取っといてある;-)。

で、せっかくの機会なので Intel の SSD にしてみました。選択したのは INTEL 330 Series SSDSC2CT120A3 300i で 128GB モデルです。 ThinkPad X100e に最初から付いていた HDD は 東芝製の 2.5 インチ 320GB 、 5400 回転のやつでしたが、それを交換しました。

ThinkPad X100e の HDD 交換は NotePC の裏蓋のネジを外してパカっと開けるともうアクセスできるのでそこですかさず交換です。非常に簡単に HDD を交換できます。

WindowsOS 部分には 50GB 、 FreeBSD 側には 60GB にしました。ちなみに WindowsOS は Windows8 をインストールしました。

まだあまり使い込んではいませんが、実際に両方の OS での動作確認をしてみたいと思います。

1). Windows8
Windows8 は 64bit 版をインストールしました。まぁ、フツーに起動した。と、言う感じでしょうか;-)。 ThinkPad X100e のデバイスは割とサクッと認識してくれました。認識していないのは多分 3G のチップだと思います。これは Windows7 のドライバをインストールしようと思っていますがまだ試していません。

あと、 Lenovo の診断ツールとかもまだインストールしていないです。無事に動作するのかな?

で、 Windows エクスペリエンスですが、こんな結果になりました。

windows8_status.jpg

SSDに交換した以外は以前と変わらないのでこんな感じでしょうかね;-)。

2). FreeBSD/amd64 9.1-PREPELEASE
フツーにインストールしてサクサク動作しています。まぁ、特に気にすることもなく。と、いう感じでしょうか。僕の持っている ThinkPad X100e は suspend/resume するというのは以前書いていますが、今回も特に問題なく動作します。

今までは 2012/05/17 くらいの 9.0-STABLE を使い続けていたのですが、いよいよ最新版の 9.1-PREPELEASE にしてしまった。と、言う感じでしょうか。

KDE-4.8.4 の『電源管理』から suspend すると X のスクリーンセーバまでかかってくれます。すげ;-)。

if_iwn の Intel(R) PRO/Wireless 6250 は相変わらず動作が不安定ですね。 USB NIC の if_run は必須な状態です・・。orz

3). Windows8 と FreeBSD の同居
320GBの HDD から 128GB の SSD に変更し WindowsOS は 7 から 8 に変わりました。マルチブートの設定についてですが Winsodws8 側で bcdedit で書き込んであげる必要があります。

Windows8 のインストールが終わって FreeBSD/amd64 9.0-R のインストールが完了した時点では FreeBSD しか起動しなくなります。

この状態で、まず最初に試したのが FreeBSD 8.3-R の CD-ROM を持ってきて MBR にブートマネージャをインストールしてみました。 Windows7 ではブートしてくれていたのですが Windows8 ではまるっきりダメですね。 Windows8 がブートしなくなったので Windows8 のメディアでレスキューとか復旧を色々試しましたがダメだったので結局で再インストールしました。

Windows8 の再インストール後は管理者権限の DOS プロンプトから bcdedit で起動情報を設定してあげます。以前このブログでも掲載しているのでそのやり方と全く一緒で OK です。

Windows8 のブートローダはバーチャルマシンイメージが起動できたりと色々なモノがブート可能になっているのが面白いですね。

あと、 default で Windows8 をブートするようにしていると NotePC の起動直後に Windows8 のマークが表示されて Windows8 の GUI なブートメニューが表示されます。 FreeBSD を default ブートにすると Windows7 の時のようなテキストベースのブートメニューになります。

Windows8 のブートローダから FreeBSD を選択すると、いきなり BIOS のトップ画面が表示されたりするのでこれまた中々焦るというか面白い現象ですね;-)。

とまぁ、こんな感じで HDD からSSD に変更したのですが、ネタ的には Widnows8 とのマルチブートについて。になってしまったでしょうかねぇ;-)。

皆さんも Windows8 で色々検証したり遊んでみてくださいー;-)。

あ。本当に最後に一点。 bcdedit は、くれぐれも管理者権限の DOS プロンプトから実行してください。管理者権限の PowerShell から実行してもまるでコマンドを受け付けてくれません・・。orz。

4月 102012
 

いやはや。僕が利用している NotePC は以前のエントリにも書いたかもしれないですが ThinKPad X100e です。この NotePC は AMD の CPU を利用していて E-350 です。時々熱がこもって ACPI shutdown が走ったりするんですけども、NotePC では唯一 X11 の drm が動作する VESA ではない(ドライバは xf86-video-ati を利用しています)最後の NotePC なのではないかなぁ。と思っているところですが;-)。

で、この NotePC は現在 FreeBSD/amd64 9.0-STABLE がインストールされているんですが、つい最近までは suspend/resume しなかった。9.0-PRERELEASE までは suspend/resume していたんだけど、その後 RC になってからは ACPI 周りの問題からか、acpiconf -s3 すると resume はブラックアウトでフリーズ、あげくの果てには AC コンセントを抜き差ししないとブートさえもしてくれない状態だったので、もう本当にある意味あきらめていたんですけどね。

さすが CURRENT および STABLE は『生もの』ですね。 2012/04/07 辺りの 9.0-STABLE を csup して make build world と install したら見事に suspend/resume が復活しました。パチパチパチ;-)。

今回はその様子を動画に撮ってみたのでちょっと公開してみましょう;-)。こんな感じ。一分07秒の動画です。


20120410.jpg

※ “再生アイコン” が見えない表示されないブラウザの場合は上記写真をクリックしてください。

いやね。雰囲気的に resume は MacBook に近い動作をします。以下、寝て起きる上記の説明です。

1. Fn+F4 で suspend します。
2. X の画面からコンソールの画面にひとまず落ちてから寝ます。
2. 手前の緑の LED が二個点きました。右側が「スリープ状態」を示しています。
3. フタを明けて resume。緑の LED は一個だけの点灯になります。
4. resume 後は X が即座に表示され早速利用可能。
5. USB Wi-Fi の run0 を利用していますが、その LED が点滅し、しばらく後に利用可能。

とまぁ、動画的にはこんな感じで suspend/resume します。上記で「MacBook に近い動作」と書いたのはフタを明けてから利用できるようになるまでの時間のことを言っています。フタを明けるとただちに X が動作するのはこれまたすごいっ!! 今までの FreeBSD にはちょっと無い体験でした。

後、何回 suspend/resume をしても特に問題なくちゃんと寝て起きてくれます。 jobs の言うところの “It just works.” って感じでしょうか;-)。

で、まだあまり試していないのですが、一点問題があるように感じます。一番最初。電源投入後、一回目の suspend だけはどうやら Ctrl+Alt+F1 で X を後ろに飛ばしてからコンソールで acpiconf -s3 を打つ必要があるみたいです。で、その時の resume はちゃんと起きて Ctrl+Alt+F3 辺りで X の画面を戻したあと、以降は Fn+F4 で寝て、そして起きてくれるようになります。この辺りがまぁ、なんちゅーか本中華なんですが、もしかしたら僕の気のせいかもしれません;-)。

で、これだけサクサク suspend/resume が動作するんだから KDE4 の電源管理で Windows7 みたいに一定時間後には寝てくれるんかいな?などと、ちょっと思ってしまうのでありますが、実際に試してみました。

PowerProfile_1.jpg

KDE4 のコントロールパネルから「電源管理」メニューで色々設定してみます。あと、タスクバーにも電源管理アイコンがあって、ここからレジュームとかハイバネードとかシャットダウンとかあるんですけどね。

今回は PowerSave の設定で 10 分後に「スリープ」と設定して放置してみました。

あたたた・・。サスペンドはしてちゃんと寝てくれます。しかし、レジューム(起動)時には X がブラックアウトしていまいました。ただし、カーネルは死んでないので ACPI S5 ステートとかリモートからの ssh は可能なので本当に X の画面のみが見えない状態。と、いう感じでした。これは上で書いたタスクバーの電源管理から「スリープ」ボタンを押した時と同じ動作でした。

と、いうことは FreeBSD 単体ではサクサク suspend/resume するけど、 KDE4 経由の電源管理ではまだもう少し頑張りが必要だね。と、いう感じでしょうか。

けどもまぁ、そこまで贅沢は言いません。これだけサクサク、何回も suspend/resume してくれるのであれば全然問題はありません。今まで suspend/redume が動作するのは二回まで。三回目に起きた時には画面はブラックアウトだっただけにずいぶんと進歩してそして非常に嬉しいのであります。

上にも書いたとおり、CURRENT や STABLE は生ものです。次回 csup してカーネルを作り替えたら動作しなくなるかもしれません。なので、今回の環境は非常にじゅーよー。みたいな。この環境でずっと使い続けたい気分です;-)。

なお、今回はこのブログ初の動画でしたが、今後は機会があれば色々、動くものを掲載して行きたいと思います;-)。

10月 072010
 

ThinkPad X100e の三回目です。これで最後になるか?! と、言う感じなのですが、僕がこの X100e を購入した後に Lenovo から新製品が出たり DELL から AthonII X2 な CPU の NotePC が出たりしてちょっと悲しいことが続いている、つまりはまぁ、僕が購入したタイミングが非常に悪かった。と言うことになるのですけども・・。orz。

と、言うことで今回は X100e で FreeBSD を利用した時の Suspend と Resume についてのお話です。「ThinkPad X100e で FreeBSD。気がついた点。」のエントリーでは「サスペンド・レジューム動きません。」とキッパリと書いたのですが、色々試したら、X 無しだと Suspend して Resume することが確認できました。FreeBSD もドンドンと進んでいると言うことですねぇ・・。大変失礼しました・・。

試した方法ですが、全てのカーネルモジュールを unload します。でもって必要最小限のカーネルもシュールのみで起動します。以下はそのモジュールのリストです。

kernel
acpi_ibm.ko
random.ko
if_re.ko
miibus.ko
procfs.ko
pseudofs.ko
ipfw.ko
libalias.ko
radeon.ko
drm.ko
agp.ko

 
ファイルシステム系のモジュールはあってもなくても大丈夫でしょう。ネットワーク系モジュールはリモートから ssh する用です。後、random もですね。その他に X 系のモジュールをロードしました。
僕は ATA 系周りはモジュールにしていません。

この状態で色々試したわけです。acpi_video は動作が怪しい kldunload acpi_video するとマシンがフリーズするので利用しないことにしました。後は sysctl の設定ですが、 /etc/sysctl.conf には以下の設定を入れました。

#hw.acpi.standby_state=S3
hw.acpi.suspend_state=S3
hw.acpi.thermal.min_runtime=300
hw.acpi.battery.info_expire=30
hw.acpi.power_button_state=S5
hw.acpi.sleep_button_state=S3
hw.acpi.lid_switch_state=NONE
hw.acpi.reset_video=1 hw.syscons.sc_no_suspend_vtswitch=1
vfs.usermount=1 hw.snd.default_unit=1

 
hw.acpi.reset_video と hw.syscons.sc_no_suspend_vtswitch を 1 にするとレジューム後に画面が表示されるようになります。

まずは X を起動せずにコンソールから acpiconf -s3 と叩くと「ヒューン」とか言ってスリープします。でもってパワーボタンはブリンクします。その後しばらくしてからパワーボタンを押すと。おぉーーっ!! 無事に復活するのであります。リモートからの ssh も接続が復活していてコマンドも受け付けてくれます。また、コンソールからもコマンドがバシバシ打てるのであります。

この辺りはミョーに感動です;-)。

と、言うことで、次に X を起動して KDE4 でログインしてから acpiconf -s3 を試してみます。スリープした後にパワーボタンを押すとバックライトは点灯するのですが、X の画面が出てきません。

ssh は利用可能なので、dev.acpi_ibm.0.lcd_brightness や dev.acpi_ibm.0.events 、そして hw.acpi.reset_video などの値を変更してみるのですが、復活する兆しは全く無いのでありました。

しゃーないので shutdown します。

次に試したのは X を起動して KDE4 でログインした後に CTRL-ALT-F1 して X の画面を一旦閉じてコンソールの画面にします。この時、コンソールではベコベコ文字が打てる状態なので acpiconf -s3 します。でもってサスペンドした後にパワーボタンを押すと、おぉっ!! コンソール画面は無事に返ってました。ここでコマンドもベコベコ打てます。

では、さっき CTRL-ALT-F1 しているので、今度は CTRL-ALT-F2 や CTRL-ALT-F3 を押して X の画面を戻すべ。とか思うのですが、ここで再度ブラックアウト。orz バックライトが点いているだけにちょっと悲しい状態なのですが、レジューム後に X が表示されることはないのでありました・・。orz

ちなみに、この状態の時、drm.ko は膨大な量のログを吐きまくっております。以下のようなログなんですけども。

info: [drm] wait idle failed status : 0xA0003030 0x00000003

 
なので問題は drm.ko 側にあるのかなぁ?などとも思えるのですが、vesa.ko でやったらどうなんだ?とか、色々あるわけなんですけどもね。

とりあえず、xf86-video なドライバは radeonhd と radeonhd-devel を試してみましたが、とちらも症状は一緒でした。とほほ。vesa ドライバでも試してみましたが、vesa の場合、ちょっと症状が変わって、壊れた X の画面が表示されたりましたが、X がまともに使える状態ではありませんでした。vesa の場合は drm.ko とか kldunload したら症状変わったりするかなぁ・・。

と、言うことで、X 無しでは無事にサスペンド・レジュームすることを確認しました。ただ、必要最低限のカーネルモジュールをロードしての確認なのですけどね。そもそも、X が動かないので、これ以上、カーネルモジュールをロードしてテストしても仕方がない。と言うのが素直な僕の感想なのですけども・・。

ThinkPadX100e は Radeon なんだけど、Core2Duo の Intel 系のグラフィックスチップの場合、無事に drm.ko も動作するのかなぁ? それがちっくと疑問なのですけども。

9月 282010
 

前回のエントリーで ThinkPad X100e 買いました−。っての書きました。でもって Windows7 x64 と FreeBSD/amd64 8.1-STABLE が動いているわけですが、今回は FreeBSD での動作についてちょっとまとめてみたいと思います。

1. サスペンド・レジューム動きません。
acpiconf -s3 で寝ることはできます。パワー LED もちゃんとブリンクするので「お。寝たか?」とか思うのですが、電源投入するとそこでフリーズします。 s5 も動きません。
FreeBSD の サスペンド・レジューム は SMP カーネルの場合、コードがスパっと抜け落ちているそうなので絶対に動作しないのでありますね。はい。ただ、シングル CPU カーネルの場合は動作するのかなぁ?試していませんし、試そうとも思いませんが・・。

2010/10/19 加筆
サスペンド・レジュームについては「ThinkPad X100e を FreeBSD で Suspend/Resume。」を参照してください。


2. 無線 LAN if_iwn は動作しません。
ThinkPad X100e は AMD のアーキテクチャなのに無線 LAN 周りは Intel のセントリーノ技術を使ってイいるんですね。利用しているチップは if_iwn 対応で Intel(R) PRO/Wireless 6250 と、言うヤツです。これと USB 接続の WiMAX 対応チップがセットになったヤツらしいのですが、以下のメッセージが出力され動作しません。

iwn0: iwn5000_send_calibration: could not send calibration result, error 22
iwn0: iwn_init_locked: could not initialize hardware, error 22

 
if_iwn.c のソースコードをチロっと眺めたところ、本来であれば iwn6250 版台(ファームウェア的には 6050 かなぁ?)なのに if_iwn.c のコード的には iwn5000 のファームウェアで動いているっぽいのでその辺りが影響しているのかもしれません。

なお、Intel(R) PRO/Wireless 625 は 802.11n に対応しているので 300Mbps 出る(論理値)のですが、ドライバ側では 802.11a/b/g にしか対応してないので 54Mbps しか速度が出ません。コード的には #if 0 って部分ですが、更に必要な define が無いのでどうしようもない状態・・。

3.サウンドチップは特殊でした。
NotePC 的にはスピーカがついているのにそこから音は出ない。けど、イヤホンジャックにヘッドホンを接続すると音が出ている。あれあれあれ?って感じですが、cat /dev/sndstat してみるとデバイスが二つ認識しているようです。

$ cat /dev/sndstat
FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64)
Installed devices:
pcm0: <HDA Conexant CX20582 (Pebble) PCM #0 Analog> (play/rec)
pcm1: <HDA Conexant CX20582 (Pebble) PCM #1 Analog> (play/rec) default

 
なんとっ!! pcm1 がスピーカ側のデバイスで、pcm0 がヘッドホン側のデバイスです。普段は sysctl -w hw.snd.default_unit=1 しておいて、ヘッドホンで聞く時は hw.snd.default_unit=0 する必要があります。

これは KDE-4.5.1 の Kmix (サウンドミキサーアプリ)のキャプチャですが、それぞれのデバイスのためにボリューム(「OSS Audio Mixier」ってヤツのタブ)が二つあります。ヘッドホン用とスピーカー用ですね。いやぁ。ちょっと驚き。最近の NotePC ってみんなこうなのかな?

thinkpadx100e2_1.png

mplayer とか立ち上げて映画とか見ていた場合、最初はスピーカーで聞いていたけど、ヘッドホンにしたい場合は sysctl -w hw.snd.default_unit=0 とか打つ必要があります。てもって音の出力先が変わったので mplayer は再起動し直しとなります。ふむー。

4. Fn+F?? キー使えません。
Fn+ テンキーって、ベンダ向けに用意されている acpi_*.ko をロードすれば Fn+ テンキー が利用できると思っていたのだけど、acpi_ibm.ko をkldload してもキーがマッピングされないので、音のボリューム・無線 LAN のオン/オフ・ディスプレーの明るさが変更できません。orz。 僕が最近の NotePC を知らないだけなのかも。技を知っている方、教えてください。

無線 LAN はそもそも利用しないのでずっとオフでも良いかも;-|。まぁ、仮に動作するようになったとしたら kldload/kldunload if_iwn.ko すればいーや。とか思っているんですが;-)。
音の大きさはミキサーアプリで調整するのでこれまたなんとかなりそう。
ディスプレーの明るさは acpi_video.ko を kldload すると sysctl MIB として hw.acpi.video.lcd0.brightness と言うのが生えてくるのでそこで明るさを指定します。以下のようなスクリプトを書けば良いかなー。って感じなのでありますが・・。

#!/bin/sh
sudo sysctl -w hw.acpi.video.lcd0.brightness=$1

 

多少使い込んで気がついたのはこんな感じでしょうか。まぁ、多分、標準的な「NotePC にインストールした FreeBSD の動作。」だと、僕は思っているのですけどねぇ;-P。

if_iwn は当分更新される予定は無いみたいなので半分あきらめです。最近は Windows7+IE9 も中々良いと思えるのでどうしても無線 LAN が必要な場合は Windows7 利用するかも;-P。まぁ、その前に iPhone4 があるので、多分めったに NotePC を門外に持ち出すことは無いと思うのだけどねぇ;-)。

7月 022007
 

カーネルモジュールのお話。特に DELL 製 NotePC 系でのお話。xorg.conf のお話。なんか、いろんなことが絡んでいるなぁ・・。

xorg が 7.2 になったので合せて色々なものが動く様になったり動かない様になったり、目に付くようになった今日このごろ、僕の持っている DELL X1 の NotePC において /var/log/Xorg.0.log を眺めていると、 /dev/agpgart が無いゼイッって怒られている行が合った。

/dev/agpgart が無いとどうなるのかと言うと drm が動かないので mplayer がフル画面で表示してくれないとか 3D が遅いかもとか言った弊害が出てくる。まぁ、そんなに大した問題では無いのだけどね(^^;;。

では、どうして /dev/agpgart が出来ないのか? どうやらカーネルモジュールをロードする時に問題がありそうだ。acpi_video.ko を先にロードしてから agp.ko、drm.ko、i915.ko をロードすると /dev/agpgart が生えてこないみたい。

そして、acpi_video.ko をロードしないようにすると /dev/agpgart が無事に生えてくる。この辺り、pciconf -lv するとデバイスの認識状況が楽しかったりします;-)。

それにしても、/dev/agpgart が生えてこないんだったら acpi_video.ko をロードしなければいいじゃん。となるんだけど、これがまたねぇ・・。DELL X1 は中途半端に suspend/redume するもんだから acpi_video.ko をロードしておかないとディスプレーのリセットとかできなくなってします。

解り易いのは acpi_video.ko をロードした時としない時の sysctl -a | grep video の違いを見れば一目瞭然。

前者の場合、外部ディスプレー出力にも対応しているのに対して、後者の場合は video 周りの ACPI (と言うか sysctl の MIB) は何も無い状態。その状態で acpiconf -s3 なんざ叩いたらマシンがあっと言う間に凍りついてしまう。

mplayer をフル画面で見たいがため、もしくは Xorg.0.log からエラーメッセージを除去したいがために acpi_video.ko をロードしないのはあまりにもナンセンスだ・・。

と、言うか、agp.ko と acpi_video.ko で drm 辺りが競合してしまうのに問題があると言うか、なんちゅーか本中華・・。

デスクトップの i915 だったら無条件で acpi_video.ko をロードしないと言う選択枝が取れるんだけどねぇ。NotePC の場合は悩ましい。

さて、あなたはどっちを選択しますか!?