diff --git a/ja/FAQ/hackers.sgml b/ja/FAQ/hackers.sgml index 23b593521b..ed8b1f5b87 100644 --- a/ja/FAQ/hackers.sgml +++ b/ja/FAQ/hackers.sgml @@ -1,269 +1,466 @@ - + - + まじめな FreeBSD ハッカーだけの話題

訳: &a.iwasaki;.8 November 1997. SNAP とか RELEASE とかは何?

現在, FreeBSD の には, 三つのアクティブ/準アクティブなブランチがあります.

現在, 自分用のカスタムリリースを構築するには?

リリースを構築するには三つのことが必要です: まず, ドライバが組み込まれたカーネルを実行させている必要があります. 以下をカーネルコンフィグレーションファイルに追加し, カーネルを作り直してください: pseudo-device vn #Vnode driver (turns a file into a device)

次に, CVS リポジトリ全体を手元においておく必要があります. これを入手するには が使用できますが, supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります: *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all

そして 最後に, ビルド用にかなりの空き領域を用意する必要があります. そのディレクトリを /some/big/filesystem として, 上の例で CVS リポジトリを /home/ncvs に置いたものとすると, 以下のようにしてリリースを構築します: setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release

処理が終了すると, リリース全体が /some/big/filesystem/release に構築され, 完全な FTP インストール用の配布物が /some/big/filesystem/release/R/ftp に作成されます. -current 以外の開発ブランチの SNAP を自分で構築したい場合は, カスタムのインストールディスクを作るにはどうすればいいのですか?

/usr/src/release/Makefile のいろいろなターゲットとして インストールディスク, ソース, バイナリアーカイブを作る完全な処理を 自動的におこなうようになっています. Makefile に十分な情報があります. しかし, 実行には ``make world'' が必要で, 多くの時間とディスクの容量が必要です. ``make world'' をおこなうと既存のバイナリを上書きしてしまうのですが.

ええ, それが一般的な考え方です. 名前が示しているように ``make world'' はすべてのシステムのバイナリを一から作り直しますので, 結果としてクリーンで一貫性のある環境を得ることができます (これがそれだけ長い時間がかかる理由です).

環境変数 ${DESTDIR}を root とみなした ディレクトリツリーにインストールされます. あるでたらめな共有ライブラリの変更やプログラムの再構築によって `` システムブート時に ``(bus speed defaulted)'' とメッセージが出ます.

アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に バスアクセス速度の設定をおこなうことができます. 以前のバージョンの 1542 ドライバは使用可能な最大の速度を求めてアダプタを その設定にしようとしました. これは特定のユーザのシステムでは 問題がある事がわかり, 現在ではカーネルコンフィグオプションに `` インターネットアクセスに制限があっても current を追いかけられますか?

はい, を使って ソースツリー全体のダウンロードを どのようにして配布ファイルを 240kバイトに分割しているのですか?

比較的新しい BSDベースのシステムでは split に任意のバイト境界で 分割する ``以下は /usr/src/Makefile からの例です. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) 私はカーネルに拡張をおこないました. 誰に送ればいいですか?

を参照してください.

あなたのアイディアに感謝します! PnP ISA カードの検出と初期化はどのようにおこなうのですか?

氏より:

要点は, ホストが認識されていないボードを探す時に, すべての PnP ボードが応答することのできる少数の I/O ポートがあるという ことです. それにより, PnP プローブルーチンが開始したとき, PnP ボードが存在するなら, すべての PnP ボードは自分のモデル番号を 返します. そのポートを I/O read するとプローブルーチンは 問いに対するワイアード-OR された ``yes'' を得ます. この場合は 少なくとも 1ビットが ON になります. そして, プローブルーチンは モデル ID (Microsoft/Intel によって割り当てられています) が X より小さいボードを ``オフライン'' にすることができます. この操作をおこない, 問い合わせに応答しているボードがまだ 残っているかどうかを調べます. もし ``ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit チェックサムからなります. 最初の 32 bits はベンダの識別子です. これは公表されてはいませんが, 同一のベンダから供給されている 異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことが できるように考えられます. 製造元を特定するだけのために 32 bits はいくらか過剰です.

下位の 32 bits はシリアル番号, イーサネットアドレスなどの ボードを特定するものです. ベンダは上位 32 bits が異なっていない のであれば下位 32 bits が同一である 2枚目のボードを製造することは ありません. したがって, 同じタイプの複数のボードをマシンに いれることができ, この場合でも 64 bits 全体ではユニークです.

32 bit のフィールドはすべてを 0 にすることはできません. これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない ビットを参照するからです.

システムがすべてのボードの与えられた ID を認識すると, それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して) おこないます. そして, 利用できる割り込みの選択などのボードが必要 とするリソースを検出します. すべてのボードについてこの情報を集めます.

この情報はハードディスク上の ECU ファイルなどの情報とまとめられ, マザーボードの BIOS にも結合されます. マザーボード上のハードウェア への ECU と BIOS PnP のサポートは通常は統合されていますが, 周辺機器については真の PnPであるとはいえません. しかし, BIOS の情報に ECU の情報を加えて調査することで, プローブルーチンは PnP デバイスが再配置できなくなることを 避けることができます.

それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ, メモリマップアドレスの設定をします. デバイスはこのアドレスに 見えるようになり, 次にリブートするまでこの位置を占めます. しかし, あなたの望む時に移動させることが不可能であるといっている わけではありません.

以上の話では大きく単純化をしてありますが, 基本的な考え方は得 られたでしょう.

マイクロソフトはボードのロジックが 対立するI/O サイクルでは デコードしていない (訳注: おそらく read 時しかデコードされていず write 時はポートが空いているという意味でしょう) プライマリプリンタのステータスポートのいくつかを PnP のために 占有しました. 私は初期の PnP の提案レビュー時に IBM 純正の プリンタボードでステータスポートの write のデコードがされている ということに気がつきましたが, MS は ``tough (頑固, 不運, 無法な)'' と言っています. そしてプリンタのステータスポートへ アドレスの設定のために write をおこなっています. また, そのアドレス + FreeBSD は, Intel 以外のアーキテクチャをサポートしないんですか?

いくつかのグループが, FreeBSD の他のアーキテクチャのサポートに関心を 示しており, 現在数人が DEC の協力を得て FreeBSD の ALPHA アーキテクチャへの 移植に取り組んでいます. 新しいアーキテクチャに関する一般的な議論は <freebsd-platforms@FreeBSD.ORG> をご利用ください. デバイスドライバを開発したので, メジャー番号が必要です.

これは, 開発したドライバを公開するかどうかに依存します. 公開するのであれば, ドライバのソースコード, files.i386 の変更, コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの 問題により公開できない場合は, キャラクタメジャー番号 32 もしくは ブロックメジャー番号 8 が, このような目的のために予約されています. これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を <freebsd-hackers@FreeBSD.ORG> に流して頂けると助かります. - + + 代替のディレクトリ配置ポリシー +

+ + 現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い + たものから全く変更されていません. 私は当初の配置ポリシーを, オリ + ジナルの fast filesystem のために書き, まったく改定していません. + このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき + ましたが,お気づきの方もいる通り find の動作には不適切です. ほと + んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます) + によって作られたアーカイブからレストアして作成されます. この際, + ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ + 優先検索を行うには考え得る限り最悪の状態になります. もし作成する + ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 / + シリンダグループ数)個のディレクトリをシリンダグループごとにまと + めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ + うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ + ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し + てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用 + いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用 + したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ + レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む + という手順が使えるでしょう. とにかく私の結論は, そろそろ実験 + を始めて見る時期だろうということです. + + + カーネルパニックを最大限に利用する + +

+ [この節は, freebsd-current に + が投稿したメールを, が校正し,括弧内のコ + メントを追加して引用したものです. ] + +

+ +From: Bill Paul +Subject: Re: the fs fun never stops +To: ben@rosengart.com +Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) +Cc: current@FreeBSD.ORG + + +

+ [<ben@rosengart.com> が以下のパニックメッセージを + 投稿しました.] + +> Fatal trap 12: page fault while in kernel mode +> fault virtual address = 0x40 +> fault code = supervisor read, page not present +> instruction pointer = 0x8:0xf014a7e5 + ^^^^^^^^^^ +> stack pointer = 0x10:0xf4ed6f24 +> frame pointer = 0x10:0xf4ed6f28 +> code segment = base 0x0, limit 0xfffff, type 0x1b +> = DPL 0, pres 1, def32 1, gran 1 +> processor eflags = interrupt enabled, resume, IOPL = 0 +> current process = 80 (mount) +> interrupt mask = +> trap number = 12 +> panic: page fault + + +

このようなメッセージが表示された場合, 問題が起きる状況を確認し + て, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ + 値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, こ + の値は使っているカーネルのイメージに依存するのです. もしスナップショッ + トなどの GENERIC カーネルを使っているのであれば, 他の人間が問題の + ある関数について追試をすることができますが, カスタマイズされたカー + ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない + のです. + +

何をすれば良いのでしょう？ + + + 命令ポインタ値をメモします. システムがリブートしたら, 以下の操作を行います: + +% nm /kernel.that.caused.the.panic | grep f0xxxxxx + + ここで, +% nm /kernel.that.caused.the.panic | grep f0xxxxx + + これでも一致しない場合は, 桁を減らしながら何らかの出力があるま + で繰り返してください. 何か出力されたら, それがカーネルパニック + を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける + 正確な方法ではありませんが, 何もないよりましです. + + + +

このようなパニックメッセージを投稿している人はよく見掛けますが, + このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数 + とつき合わせて調べている人はまれです. + +

パニックの原因を突き止める最良の方法は, クラッシュダンプをとり, + + どっちにしろ, 私は普通以下のようにします. + + + カーネルコンフィグファイルを作ります. カーネルデバッガが + 必要そうであれば options 'DDB' を加えても良いです(私は永久ルー + プが起こっていそうな場合に, ブレークポイントを設定するのに使って + います). + + cd /sys/compile/KERNELCONFIG; make + カーネルのコンパイルが終了するのを待ちます. + cp kernel / + reboot + + +

[注: 現在 3.0-BETA では, + +

全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は + ありません. 確実にクラッシュダンプをとるには, /etc/rc.conf を編 + 集して /etc/rc.conf で設定されていれ ば, /var/crash に保存します. + +

注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ + イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ + シュ ダンプが生成されることになります. /var/crash に十 + 分な空き 容量があることを確認してください. 手動で + クラッシュダンプを取り出せたら, 以下のように + +% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 +(gdb) where + +

必要な情報が 1 画面に収まらないことも多いので, できれば + もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる + 環境にあれば, [Bill による注: DDB を有効にしていてカーネルがデバッガに + 落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ + クを 起こしクラッシュダンプさせることができます. パニックの途中 + で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ + ば, クラッシュダンプを最後まで実行させられます.] + + diff --git a/ja_JP.eucJP/FAQ/hackers.sgml b/ja_JP.eucJP/FAQ/hackers.sgml index 23b593521b..ed8b1f5b87 100644 --- a/ja_JP.eucJP/FAQ/hackers.sgml +++ b/ja_JP.eucJP/FAQ/hackers.sgml @@ -1,269 +1,466 @@ - + - + まじめな FreeBSD ハッカーだけの話題

訳: &a.iwasaki;.8 November 1997. SNAP とか RELEASE とかは何?

現在, FreeBSD の には, 三つのアクティブ/準アクティブなブランチがあります.

現在, 自分用のカスタムリリースを構築するには?

リリースを構築するには三つのことが必要です: まず, ドライバが組み込まれたカーネルを実行させている必要があります. 以下をカーネルコンフィグレーションファイルに追加し, カーネルを作り直してください: pseudo-device vn #Vnode driver (turns a file into a device)

次に, CVS リポジトリ全体を手元においておく必要があります. これを入手するには が使用できますが, supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります: *default prefix=/home/ncvs *default base=/a *default host=cvsup.FreeBSD.org *default release=cvs *default delete compress use-rel-suffix ## Main Source Tree src-all src-eBones src-secure # Other stuff ports-all www doc-all

そして 最後に, ビルド用にかなりの空き領域を用意する必要があります. そのディレクトリを /some/big/filesystem として, 上の例で CVS リポジトリを /home/ncvs に置いたものとすると, 以下のようにしてリリースを構築します: setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release

処理が終了すると, リリース全体が /some/big/filesystem/release に構築され, 完全な FTP インストール用の配布物が /some/big/filesystem/release/R/ftp に作成されます. -current 以外の開発ブランチの SNAP を自分で構築したい場合は, カスタムのインストールディスクを作るにはどうすればいいのですか?

/usr/src/release/Makefile のいろいろなターゲットとして インストールディスク, ソース, バイナリアーカイブを作る完全な処理を 自動的におこなうようになっています. Makefile に十分な情報があります. しかし, 実行には ``make world'' が必要で, 多くの時間とディスクの容量が必要です. ``make world'' をおこなうと既存のバイナリを上書きしてしまうのですが.

ええ, それが一般的な考え方です. 名前が示しているように ``make world'' はすべてのシステムのバイナリを一から作り直しますので, 結果としてクリーンで一貫性のある環境を得ることができます (これがそれだけ長い時間がかかる理由です).

環境変数 ${DESTDIR}を root とみなした ディレクトリツリーにインストールされます. あるでたらめな共有ライブラリの変更やプログラムの再構築によって `` システムブート時に ``(bus speed defaulted)'' とメッセージが出ます.

アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に バスアクセス速度の設定をおこなうことができます. 以前のバージョンの 1542 ドライバは使用可能な最大の速度を求めてアダプタを その設定にしようとしました. これは特定のユーザのシステムでは 問題がある事がわかり, 現在ではカーネルコンフィグオプションに `` インターネットアクセスに制限があっても current を追いかけられますか?

はい, を使って ソースツリー全体のダウンロードを どのようにして配布ファイルを 240kバイトに分割しているのですか?

比較的新しい BSDベースのシステムでは split に任意のバイト境界で 分割する ``以下は /usr/src/Makefile からの例です. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) 私はカーネルに拡張をおこないました. 誰に送ればいいですか?

を参照してください.

あなたのアイディアに感謝します! PnP ISA カードの検出と初期化はどのようにおこなうのですか?

氏より:

要点は, ホストが認識されていないボードを探す時に, すべての PnP ボードが応答することのできる少数の I/O ポートがあるという ことです. それにより, PnP プローブルーチンが開始したとき, PnP ボードが存在するなら, すべての PnP ボードは自分のモデル番号を 返します. そのポートを I/O read するとプローブルーチンは 問いに対するワイアード-OR された ``yes'' を得ます. この場合は 少なくとも 1ビットが ON になります. そして, プローブルーチンは モデル ID (Microsoft/Intel によって割り当てられています) が X より小さいボードを ``オフライン'' にすることができます. この操作をおこない, 問い合わせに応答しているボードがまだ 残っているかどうかを調べます. もし ``ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit チェックサムからなります. 最初の 32 bits はベンダの識別子です. これは公表されてはいませんが, 同一のベンダから供給されている 異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことが できるように考えられます. 製造元を特定するだけのために 32 bits はいくらか過剰です.

下位の 32 bits はシリアル番号, イーサネットアドレスなどの ボードを特定するものです. ベンダは上位 32 bits が異なっていない のであれば下位 32 bits が同一である 2枚目のボードを製造することは ありません. したがって, 同じタイプの複数のボードをマシンに いれることができ, この場合でも 64 bits 全体ではユニークです.

32 bit のフィールドはすべてを 0 にすることはできません. これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない ビットを参照するからです.

システムがすべてのボードの与えられた ID を認識すると, それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して) おこないます. そして, 利用できる割り込みの選択などのボードが必要 とするリソースを検出します. すべてのボードについてこの情報を集めます.

この情報はハードディスク上の ECU ファイルなどの情報とまとめられ, マザーボードの BIOS にも結合されます. マザーボード上のハードウェア への ECU と BIOS PnP のサポートは通常は統合されていますが, 周辺機器については真の PnPであるとはいえません. しかし, BIOS の情報に ECU の情報を加えて調査することで, プローブルーチンは PnP デバイスが再配置できなくなることを 避けることができます.

それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ, メモリマップアドレスの設定をします. デバイスはこのアドレスに 見えるようになり, 次にリブートするまでこの位置を占めます. しかし, あなたの望む時に移動させることが不可能であるといっている わけではありません.

以上の話では大きく単純化をしてありますが, 基本的な考え方は得 られたでしょう.

マイクロソフトはボードのロジックが 対立するI/O サイクルでは デコードしていない (訳注: おそらく read 時しかデコードされていず write 時はポートが空いているという意味でしょう) プライマリプリンタのステータスポートのいくつかを PnP のために 占有しました. 私は初期の PnP の提案レビュー時に IBM 純正の プリンタボードでステータスポートの write のデコードがされている ということに気がつきましたが, MS は ``tough (頑固, 不運, 無法な)'' と言っています. そしてプリンタのステータスポートへ アドレスの設定のために write をおこなっています. また, そのアドレス + FreeBSD は, Intel 以外のアーキテクチャをサポートしないんですか?

いくつかのグループが, FreeBSD の他のアーキテクチャのサポートに関心を 示しており, 現在数人が DEC の協力を得て FreeBSD の ALPHA アーキテクチャへの 移植に取り組んでいます. 新しいアーキテクチャに関する一般的な議論は <freebsd-platforms@FreeBSD.ORG> をご利用ください. デバイスドライバを開発したので, メジャー番号が必要です.

これは, 開発したドライバを公開するかどうかに依存します. 公開するのであれば, ドライバのソースコード, files.i386 の変更, コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの 問題により公開できない場合は, キャラクタメジャー番号 32 もしくは ブロックメジャー番号 8 が, このような目的のために予約されています. これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を <freebsd-hackers@FreeBSD.ORG> に流して頂けると助かります. - + + 代替のディレクトリ配置ポリシー +

+ + 現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い + たものから全く変更されていません. 私は当初の配置ポリシーを, オリ + ジナルの fast filesystem のために書き, まったく改定していません. + このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき + ましたが,お気づきの方もいる通り find の動作には不適切です. ほと + んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます) + によって作られたアーカイブからレストアして作成されます. この際, + ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ + 優先検索を行うには考え得る限り最悪の状態になります. もし作成する + ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 / + シリンダグループ数)個のディレクトリをシリンダグループごとにまと + めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ + うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ + ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し + てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用 + いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用 + したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ + レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む + という手順が使えるでしょう. とにかく私の結論は, そろそろ実験 + を始めて見る時期だろうということです. + + + カーネルパニックを最大限に利用する + +

+ [この節は, freebsd-current に + が投稿したメールを, が校正し,括弧内のコ + メントを追加して引用したものです. ] + +

+ +From: Bill Paul +Subject: Re: the fs fun never stops +To: ben@rosengart.com +Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) +Cc: current@FreeBSD.ORG + + +

+ [<ben@rosengart.com> が以下のパニックメッセージを + 投稿しました.] + +> Fatal trap 12: page fault while in kernel mode +> fault virtual address = 0x40 +> fault code = supervisor read, page not present +> instruction pointer = 0x8:0xf014a7e5 + ^^^^^^^^^^ +> stack pointer = 0x10:0xf4ed6f24 +> frame pointer = 0x10:0xf4ed6f28 +> code segment = base 0x0, limit 0xfffff, type 0x1b +> = DPL 0, pres 1, def32 1, gran 1 +> processor eflags = interrupt enabled, resume, IOPL = 0 +> current process = 80 (mount) +> interrupt mask = +> trap number = 12 +> panic: page fault + + +

このようなメッセージが表示された場合, 問題が起きる状況を確認し + て, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ + 値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, こ + の値は使っているカーネルのイメージに依存するのです. もしスナップショッ + トなどの GENERIC カーネルを使っているのであれば, 他の人間が問題の + ある関数について追試をすることができますが, カスタマイズされたカー + ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない + のです. + +

何をすれば良いのでしょう？ + + + 命令ポインタ値をメモします. システムがリブートしたら, 以下の操作を行います: + +% nm /kernel.that.caused.the.panic | grep f0xxxxxx + + ここで, +% nm /kernel.that.caused.the.panic | grep f0xxxxx + + これでも一致しない場合は, 桁を減らしながら何らかの出力があるま + で繰り返してください. 何か出力されたら, それがカーネルパニック + を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける + 正確な方法ではありませんが, 何もないよりましです. + + + +

このようなパニックメッセージを投稿している人はよく見掛けますが, + このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数 + とつき合わせて調べている人はまれです. + +

パニックの原因を突き止める最良の方法は, クラッシュダンプをとり, + + どっちにしろ, 私は普通以下のようにします. + + + カーネルコンフィグファイルを作ります. カーネルデバッガが + 必要そうであれば options 'DDB' を加えても良いです(私は永久ルー + プが起こっていそうな場合に, ブレークポイントを設定するのに使って + います). + + cd /sys/compile/KERNELCONFIG; make + カーネルのコンパイルが終了するのを待ちます. + cp kernel / + reboot + + +

[注: 現在 3.0-BETA では, + +

全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は + ありません. 確実にクラッシュダンプをとるには, /etc/rc.conf を編 + 集して /etc/rc.conf で設定されていれ ば, /var/crash に保存します. + +

注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ + イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ + シュ ダンプが生成されることになります. /var/crash に十 + 分な空き 容量があることを確認してください. 手動で + クラッシュダンプを取り出せたら, 以下のように + +% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 +(gdb) where + +

必要な情報が 1 画面に収まらないことも多いので, できれば + もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる + 環境にあれば, [Bill による注: DDB を有効にしていてカーネルがデバッガに + 落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ + クを 起こしクラッシュダンプさせることができます. パニックの途中 + で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ + ば, クラッシュダンプを最後まで実行させられます.] + +