検索

• [ Prev ]
• [ Next ]
• [ 技術 ]

FreeBSDでのKernelデバッグについて雑多なメモ。

一次資料：

• FreeBSD Developers' Handbook, Chapter 10 Kernel Debugging
  • http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

オンラインでDDBを起動する

KDB, DDB有効にしてカーネル再構築。

options KDB
options DDB

好きなタイミングで

# sysctl debug.kdb.enter=1

これでコンソール or シリアルコンソールでDDBが起動する。ダンプを保存したければDDB上で"panic"コマンドを実行する。

• [ Prev ]
• [ Next ]
• [ 技術 ]

たまにはアニメでも見ようかとTSUTAYAで何本か借りてきた。
で、最近やる夫AAスレで仮面ライダーのAAが増えてきたので、気になってなんとなくディケイドのvol1を見てみたんだけど、結構面白い。主人公が結構「イイ性格」しててキャラ立ちしてるなぁ。他の平成ライダーも見てみたくなってきた。
他、今更だけど「空の境界」劇場版。まだ「俯瞰風景」観終わっただけだけど、とりあえず両儀式への愛に満ち溢れた映像であることはわかった。ってか、Google日本語入力、両儀式を一発変換できた。すげぇ。

• [ Prev ]
• [ Next ]
• [ 技術 ]

とりあえず下記handbookの内容を抄訳メモ。

• FreeBSD Developers' Handbook, Chapter 10 Kernel Debugging, 10.7 Debugging Loadable Modules Using GDB
  • http://www.es.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-kld.html

他、"FreeBSD loadable module debug"などでググる。

で、上の内容なんだけど www."es".freebsd.org で見つかって、www.freebsd.orgの方には無い(2011-01-07時点)。
なんで、ちょっと不安。

あとあくまでもざっくり意訳したメモ書きで、実際に試してはいません。

1. デバッグ情報付きでモジュールをコンパイル

例としてlinux.ko:

# cd /sys/modules/linux
# make clean; make COPTS=-g

2. モジュールがロードされたアドレスを見つける

リモートからGDBでデバッグしてる(オンライン)場合：デバッグ機でkldstatすればLinker File= .koファイルがロードされたアドレスが分かる。
例：

# kldstat
Id Refs Address    Size     Name
 1    4 0xc0100000 1c1678   kernel
 2    1 0xc0a9e000 6000     linprocfs.ko
 3    1 0xc0ad7000 2000     warp_saver.ko
 4    1 0xc0adc000 11000    linux.ko

→ 0xc0adc000 に linux.ko がロードされてる。

crashダンプをkgdbなどでデバッグしてる(オフライン)場合：linker_files->tqh_first を起点として link.tqe_next を辿り、 filename が対象のlinker file名になっているエントリを見つける。見つかったら、 address メンバが linker file がロードされたアドレスを示している。

オンライン/オフラインそれぞれの場合でlinker fileがロードされたアドレスを見つけたら、その中に含まれている実行コードのアドレス(=linker file中でのオフセット)を調べる。

# objdump --section-headers /sys/modules/linux/linux.ko | grep text
  3 .rel.text     000016e0  000038e0  000038e0  000038e0  2**2
 10 .text         00007f34  000062d0  000062d0  000062d0  2**2
                                                ^^^^^^^^ これがオフセット。

というわけで、この例なら

0xc0adc000 = linux.ko = linker fileがロードされたアドレス
+
0x000062d0 = linker file中の".text"のオフセット = 実行コードのオフセット
=
0xc0ae22d0 = 再配置後のメモリ上の実行コードのアドレス

3. GDB(kgdb)にシンボルをロードする

add-symbol-file コマンドでシンボルをロードする。
今回の例：

(kgdb) add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0
add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0?
(y or n) y
Reading symbols from /sys/modules/linux/linux.ko...done.
(kgdb)

以上。

• [ Prev ]
• [ Next ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

FreeBSDでのKernel Crash Dump, Core Dump の取得方法についてメモ。

一次資料：

• FreeBSD Developers' Handbook, Chapter 10 Kernel Debugging, 10.1 Obtaining a Kernel Crash Dump
  • http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

Dumpの取得方法それ自体については上記資料の他にも色々見つかりますが、実際に実験しようとすると、まずCrash自体を発生させないとDumpも生成されない。というわけで、最初にGENERICカーネルでもプログラミング不要で使えるpanic(9)発生方法をまとめて、その後、Dumpの取得方法や必要な設定についてまとめます。
FreeBSD 6.0-RELEASEで確認してます。

Kernel Panic の起こし方

Crash Dumpの解析をしてみたいが、そのためにはKernel Panicが発生する必要がある。
panic(9)を使うのが素直な方法らしいが、そのためだけにわざわざカーネルモジュールを作るのは手間。
というわけで、とにかくpanic(9)を起こしたことにする方法。ざっとググッてみたところ２通りあるっぽい。

一つが sysctl の "debug.kdb.panic" オプションに1を設定する方法。

# sysctl -d debug.kdb.panic
debug.kdb.panic: set to panic the kernel
# sysctl debug.kdb.panic=1
→即座にpanic

出典：

• On-Line Kernel Debugging Using DDB
  • http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html

もう一つが、

# sysctl -d machdep.enable_panic_key
machdep.enable_panic_key: Enable panic via keypress specified in kbdmap(5)
# sysctl machdep.enable_panic_key=1

としておいて、現在使っているキーマップファイルで、アクションに"panic"を設定したキーを用意し、コンソールから入力する方法。
出典：

• kbdmap(5)
• Manual kernel panic - The FreeBSD Forums
  • http://forums.freebsd.org/showthread.php?t=10024

"debug.kdb.panic"の方法については、昨日から使い始めたFreeBSD 6.0-RELEASEでは

# sysctl -d debug.kdb.panic
sysctl: unknown oid 'debug.kdb.panic'

となってしまい認識されない。

"machdep.enable_panic_key"については、少なくとも2004年7月頃にパッチが投稿されているので、それ以降なら使える可能性が高い。
2005年11月リリースのFreeBSD 6.0-RELEASEで問題なく機能した。

• freebsd-current: Documenting machdep.enable_panic_key?
  • http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-07/2358.html

というわけで"machdep.enable_panic_key"によりpanic発生方法についてメモ。
FreeBSD 6.0-RELEASEのGENERICカーネルでも使える。

まずこのオプションに1を設定する。

# sysctl machdep.enable_panic_key=1

以降もずっと有効にしたければ /etc/sysctl.conf に登録しておく。

次に、現在使っているコンソールのキーマップに"panic"アクション用のキーを設定する。
"/etc/rc.conf"でキーマップを確認：

# grep keymap /etc/rc.conf
keymap="jp.106"

"keymap"の値に".kbd"を付ければ、キーマップのファイル名になる。この例なら：

/usr/share/syscons/keymaps/jp.106.kbd

がキーマップファイル名。キーマップファイルのフォーマットの詳細はkbdmap(5)参照。

とりあえず今回は"alt + ctrl + shift + p"をpanicに設定してみる。

 025   'p'    'P'    dle    dle    'p'    'P'    dle    dle     C
 →
 025   'p'    'P'    dle    dle    'p'    'P'    dle    panic     C

あとはkbdcontrol(1)でキーマップファイルをロードさせればOK.

# kbdcontrol -l /usr/share/syscons/keymaps/jp.106.kbd

これでコンソール上で"alt + ctrl + shift + p"を押せば、無事(?)Kernel Panicが発生する。GENERICカーネルならそのままCrash Dumpがswapデバイスに出力され、"options KDB" + "options DDB"付きのカーネルならDDBが起動する。
DDBが起動した場合は、

panic

コマンドでkernelのcore dump(=Crash Dump : 本当にCrashしたわけじゃないけど。)をswapデバイスに保存できる。詳細は前掲の "On-Line Kernel Debugging Using DDB" 参照。

Kernel Core Dump (Crash Dump) を保存するには

Dumpを保存するには2stepが必要。
1. kernel panic -> swapデバイスに保存される。 : dumpon(8)コマンド
2. 再起動後 -> swapデバイスからダンプデータを取り出して、適当なファイルに保存する。 : savecore(8)コマンド

基本的に "/etc/rc" により自動的に処理されるが、手動でdumpon(8)やsavecore(8)を実行することも勿論可能。
rc.conf(5)で"/etc/rc"で処理されるときのパラメータをカスタマイズすることもできる。

出典：

• FreeBSD Developers' Handbook, Chapter 10 Kernel Debugging
  • http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

手動でdumpon(8), savecore(8)を実行する

まずswapinfoでswapデバイスがonになってるか確認、適当なswapデバイスを選ぶ。

# swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ad0s1b        498504        0   498504     0%

dumpon(8)でダンプデータの保存先swapデバイスを設定する。

# dumpon /dev/ad0s1b

好みの方法でpanicを発生させ、swapデバイスにダンプデータを保存、その後 single user モードで再起動させる。
"/var/crash"などダンプファイル保存先のディレクトリをマウントし、savecore(8)でダンプファイルとして保存する。

OK>boot -s
...
# fsck -p
# mount -a
# savecore /var/crash /dev/ad0s1b
# exit

自動でdumpon(8), savecore(8)実行

基本的に "/etc/rc" が自動的にdumpon(8), savecore(8)を処理してくれる。
dumpon(8)のswapデバイスを指定したい場合は

dumpdev="/dev/ad0s1XY"

などをrc.confに設定する。
savecore(8)のダンプファイル保存先ディレクトリを指定したい場合は

dumpdir="/my/crash/files"

などをrc.confに設定する。

FreeBSD 6.0-RELEASEでは /etc/defaults/rc.conf において

dumpdev="AUTO"          # Device to crashdump to (device name, AUTO, or NO).
dumpdir="/var/crash"    # Directory where crash dumps are to be stored

が設定済みになっている。このため、殆どのケースではpanic発生時には自動的にswapデバイスにダンプデータが保存され、再起動後、自動的に"/var/crash"以下にダンプファイルが保存される。

• [ Prev ]
• [ Next ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

一次資料：

• FreeBSD Handbook : 26.6 Setting Up the Serial Console
  • http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html
• FreeBSD ハンドブック : 18.6 シリアルコンソールの設定
  • http://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/serialconsole-setup.html

DDB関連のトピック以外はGENERICカーネルで使える。もし複数のシリアルポートを使い分けたり、通信速度を変更したい場合は上記一次資料を参考に設定ファイルの変更やカーネル再構築が必要となる。

とりあえずCOM1で9600bpsのままお手軽に出来ればオッケー、みたいなノリでメモ。

起動時のカーネルメッセージをシリアルポートに出力したい or DDBをシリアルポートで制御したい

FreeBSD 6.0-RELEASE環境で、一番お手軽で準備不要なのはboot時に"-h"オプション付ける方法。

boot -h

起動時のカーネルメッセージが物理コンソールとシリアルポートの両方に出力される。

DDBが起動するときも、物理コンソールとシリアルの両方から使えるので便利。つまり、「うっかりシリアルポートに接続しないでpanicしちゃった」時も、物理コンソール側からDDBを制御できるので安心。もちろんシリアルポートに端末を接続してれば、そちらからもDDBを制御できるのでなお便利。

FreeBSD 6.0-RELEASEでは、GENERICカーネルのhintsで

hint.sio.0.flags="0x10"

が定義済み。あとは"-h"オプション使うなり、

set console="comconsole"

を/boot/loader.confに設定する or boot時のプロンプト上から直接設定するなりすればOK。

ただし、set console="comconsole" だと物理コンソールに起動時メッセージの出力とかDDBの制御が渡らなく
なってしまうので、うっかりシリアルポートに端末を接続するのを忘れたとき「ouch!!」ってなっちゃいそう。

ちなみにGENERICカーネルで"-h"によりシリアルポートに出力できるのは起動時のカーネルメッセージまで。DDBはGENERICカーネルでは当然使えない。
DDBも使おうと思ったらDDBオプション有効にしてカーネル再構築が必要。

bootメニューの段階でシリアルポートを使いたい

"/boot"をマウントしたパーティションのルートディレクトリに、"boot.conf"という名前のファイルを作り、そこに

-h
-D
-P

のいずれかを書きこむ。"-h"だとシリアルポートにだけbootメニューやカーネルメッセージが出力される。"-D"ならシリアルポートと物理コンソールの両方からbootメニューが使えて、カーネルメッセージも出力される。"-P"だとキーボードの有無がチェックされる。

個人的には、キーボードがあろうとなかろうと、シリアルと物理、両方あれば両方使う、どちらか無ければ有るほうが使えれば良い、そういうケースが多いと思うので、"-D"が好み。

これらのオプションを二つ以上組み合わせたい場合の"boot.conf"は、

-D -P

のように分けても良いし、

-DP

のようにしても良い。

シリアルコンソールからログインしたい

/etc/ttysファイルの "ttyd"(FreeBSD 8.0以降は"ttyu")端末のエントリを "off" から "on" に書き換える。

ttyd0  "/usr/libexec/getty std.9600"   dialup  off secure
→
ttyd0  "/usr/libexec/getty std.9600"   dialup  on secure

これでシリアルポート用のgettyがブート時に起動され、ログインプロンプトがシリアルコンソールに表示されログイン可能となる。

• [ Prev ]
• [ Next ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

ゲストOSのシリアルポートをNamedPipeに設定し、Windowsホスト側のアプリケーションと接続する方法のメモ。

→ "Named Pipe TCP Proxy Utility" を使ってNamedPipeをTCP/IPに中継、あとはTeraTermなりtelnetコマンドなりでお好きなWindowsアプリ使って通信できます。

Win7でもOKでした。

参考：

• Named Pipe TCP Proxy Utility
  • http://shvechkov.tripod.com/nptp.html
• Sun xVM VirtualBox上のFreeBSDへコンソール接続する｜fujisan0907のブログ
  • http://ameblo.jp/fujisan0907/entry-10358771684.html

一応TeraTerm側で自前でNamedPipeに対応する機能を追加する動きがあるようです。将来、上記のUtilityを入れなくてもTeraTermだけで接続できるようになるかもしれません。

• Ticket #13634: 名前付きパイプ - Tera Term - SourceForge.JP
  • http://pt.sourceforge.jp/ticket/browse.php?group_id=1412&tid=13634

• [ Prev ]
• [ Next ]
• [ 技術 ]

他に頭の良いやり方があるかもだけれど、とりあえず適当に "FreeBSD single user keyboard" でググッてみたりしたらできちゃったのでメモ。

まずFreeBSDのブートメニューでブートローダーのプロンプトを表示させて、

OK> boot -s

でsingle userでブートする。で、適当に/bin/shとかを起動して、

# mount -a

とかで適当にマウントして、

/usr/share/syscons/keymaps/

以下を見れるようにしておく。

で、

# kbdcontrol -l /usr/share/syscons/keymaps/jp.106.kbd

すれば使えるようになった。

# kbdcontrol -l /usr/share/syscons/keymaps/jp.106x.kbd

でも良いのかもしれない。試してないので分からないけど。

これをしておかないと、chpassとかでviを起動したとき、viコマンドの":"の入力で困ることになるので。
いや～、焦った焦った。":"を押してもviコマンドにならず、「あ、もしかして英語キーボードになってる？」ってところでググリだした次第。

最初

shutdown -h now

しても電源がOFFにならないので、適当に"FreeBSD shutdown power off"とかでぐぐってみたら、

shutdown -p now

すればOKということがわかった。へ～。
Linuxだと"-h"で電源もOFFになるんだけど、FreeBSDだと分かれてるんだ・・・。

• Shutdown Sequence
  • http://www.freebsd.org/doc/handbook/boot-shutdown.html

電源管理に関連するkernel機能となるとAPMやACPIのオプションが気になるけど、昨日から使い始めたFreeBSD-6.0のGENERICだとデフォルトでACPIが有効になっていたので、特に問題は無かった。

2004年に購入してずっと本棚に眠っていましたが、簡潔かつ短めなサンプルコードと一緒にサクサク読み進めることが出来ました。

基本と本質部分を図とともに分かりやすくガイドしてくれます。広く浅くつまみ食いできるようになってますので、アルゴリズム分野への肩の凝らない入門書としておすすめです。

オフィシャル：

• ソフトバンク クリエイティブ:プログラミングの宝箱　アルゴリズムとデータ構造
  • http://www.sbcr.jp/products/4797324198.html

家賃の都合で千葉県は習志野市に引越し、ニート・ひきこもり生活を満喫しつつ、自動車免許取得したりスキューバダイビング始めたり本棚に積まれていた技術書を消化したり知り合いのお手伝いをしたりしてました。あと近くにコナミスポーツクラブがあったので、2月位から通い始め、なんとか10kgの減量に成功しました。ダイビング始めたのもコナミスポーツクラブで誘われたのがきっかけです。

参考：2009年のまとめ：

• 日記/2009/12/31/2009年のまとめ

2010年で自分にとって印象深い出来事や本サイトの記事をまとめてみます。

• Assembler/なぜx86ではMBRが"0x7C00"にロードされるのか？(完全版)
  • はてなブックマークでも好評頂きました。自分で読み返してみると、参考資料の一覧が我ながら便利だなと。DOS時代の資料サイトが結果としてうまくまとまった感じです。
• 技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか？(擬似端末, Pseudo Terminal, SIGHUP他)
  • こちらもはてブが多かった記事です。nohupの有無で挙動が変わる点は前から気になっていたので調べてみました。
• 本棚に積まれていた技術書32冊消化
  • 何年も積みっぱなしで、「いつか読んでやる・・・！！」と心の重荷になっていた技術書の消化に明け暮れた一年とも言えます。大学時代からの宿題をようやく、片付けることが出来ました。
• 自動車免許取得
  • TSUTAYAの会員証の更新など、やっぱり取得しておいて良かったです。住所確認が必要な場面で大活躍でした。
• ダイエット
  • 長いお休みを良い機会に、手を出してみました。90kg -> 80kgと減らすことが出来ましたが、元が太ってるので、もう少し続けてみます。まだまだ体脂肪率は30%を越えてますので。

技術書の消化と並行し、不要となった本や漫画本を処分したりしました。それも減量の一種かもしれません。
良い意味で肩の力を抜くことが出来た一年です。
読み残していた技術書も、残り6冊です(余裕があればもう1-2冊)。
来年春頃から再就職の活動を始めます。

以下、月ごとの細かい振り返りです。