したがって、問題を正しく理解していれば、特定のハードウェアを必要としないカーネルモジュールがあります。モジュールを操作しているとき、システムはフリーズしますが、カーネルログには特別なものは何も含まれていません。
以下が役立つ場合があります。
ログの取得
あなたが説明した症状は、カーネルoopsまたはパニックの結果である可能性があります。ロギング機能は、エラーに関する情報をログファイルに出力する前に停止することがあります。シリアルポートを介してログを出力しようとする場合がありますが、これはより信頼性が高いはずです。
カーネルモジュールは特定のハードウェアを必要としないため、最も簡単な方法は、仮想マシンに使用するのと同じLinuxディストリビューションをインストールし、そのマシンの仮想シリアルポート（COM）をホストシステムのパイプに接続することです。
これは通常、非常に簡単です。たとえば、このブログ投稿には、ホストOSとゲストOSがUbuntu11.10の場合の詳細な手順が含まれています。
VirtualBoxは、仮想マシンを管理するためにそこで使用されます。QEMUを好む場合は、これも可能です。VirtualBoxを使用する方が少し簡単だと思いますが、個人的な好みの問題です。
基本的に、次の手順を実行する必要があります。
- 仮想マシンを作成し、そこにゲストOSとして必要なLinuxディストリビューションをインストールします。
- 仮想マシンの構成でシリアルポート（COM1、...）を有効にし、ホスト上の特別なファイル（「ホストパイプ」）に接続するように構成します
/tmp/vbox_serial。
- ゲストOSを起動し、そのブートオプションを調整します。少なくとも、
console=ttyS0,115200ブートローダーメニューのカーネルオプションにそのようなものを追加します。
- ホストで、を開始するか
minicom、socatまたはから読み取る他のすべてのもの/tmp/vbox_serial。
- それだ。これで、を介してホストシステムに注ぐゲストOSのカーネルログを取得する必要があります
/tmp/vbox_serial。ゲストシステムがクラッシュすると、ゲスト自体のファイルに保存されていなくてもログが取得されます。
物事を簡単にするために、そのブログ投稿の作成者が提案するのではsocatなく、ホストシステムで使用することができます。minicomの力minicomはおそらくここでは必要ありません。
このようにして、ログをコンソールに出力しながら、ログをファイルに保存するsocatことができます。teeguest.log
socat /tmp/vbox_serial - | tee guest.log
カーネルoopsまたはパニックが発生した場合、ログのバックトレースは通常、何が問題になっているのかを見つけるのに役立ちます。
デッドロックの検出
シリアル接続またはその他の手段で完全なログを取得しても、疑わしいものがなく、カーネルにデッドロックが発生していると思われる場合は、
lockdepツールが役立つ可能性があります。これはカーネルに含まれています（ただし、でカーネルを再構築する必要がある場合がありますCONFIG_LOCKDEP_SUPPORT=y）。
Lockdepは潜在的なデッドロックを検出し、結果をカーネルログに出力します。このプレゼンテーションは、その出力を分析するのに役立つ場合があります。
トレース施設
システムをデバッグするためにカーネル内のいくつかのイベントをトレースする必要がある場合は、便利なツールがいくつかあります。
- Kprobes-カーネル内のほぼ任意の場所に設定できる一種のブレークポイント。パフォーマンスに中程度の影響を与えながら、特に関数呼び出しをトレースするために使用できます。
- SystemTap-カーネルで何が起こっているかを分析するための強力なシステム。その一部はKprobesに基づいています。
- Ftrace-カーネルに含まれているトレースシステムは、それが重要な場合、Kprobesよりもオーバーヘッドが少なくなります。