私は、ランダムで複雑なユースケースでランダムな時間でフリーズする数千行のカーネルモジュールを備えた組み込みボードを持っています。デバッグを試みるための解決策は何ですか?
私はすでに魔法のシステムリクエストを試しましたが、うまくいきません。説明は、ハードウェア割り込みが無効になっているコードでループまたはデッドロックに陥っていることだと思いますか?
ありがとう、エヴァ。
私は、ランダムで複雑なユースケースでランダムな時間でフリーズする数千行のカーネルモジュールを備えた組み込みボードを持っています。デバッグを試みるための解決策は何ですか?
私はすでに魔法のシステムリクエストを試しましたが、うまくいきません。説明は、ハードウェア割り込みが無効になっているコードでループまたはデッドロックに陥っていることだと思いますか?
ありがとう、エヴァ。
通常、組み込みボードにはウォッチドッグがあります。このタイマーを有効にし、watchdog
ユーザー プロセスを使用してウォッチ ドッグハードウェアを起動する必要があります。プロセスで使用nice
して、watchdog
優先度の高いタスクが CPU を解放する必要があるようにします。これにより、問題に関する手がかりが得られます。ウォッチドッグがアクティブな状態でデバイスがリセットされない場合は、ネットワークまたはシリアル ポートのみが通信を停止した可能性があります。つまり、カーネルはロックアップしていません。問題は、ユーザーに表示されるアクティビティがないことです。ウォッチドッグは、この種の問題が現場で発生した場合にも役立ちます。
カーネル ロックアップの場合、ロックアップ ウォッチドッグカーネル機能が役立つ可能性があります。これは、推測どおりに無限ループ/デッドロックがある場合に機能します。ただし、これがカスタム ハードウェアである場合、SDRAMまたは周辺デバイスがラッチアップし、異常なバスアクティビティが発生する可能性もあります。これにより、CPU が適切なコードを取得できなくなります。明らかに、Linuxがこの状態から回復するのは困難です。
ウォッチドッグを、トレース バッファとして使用される空きメモリと組み合わせることができます。カーネルが使用するメモリを制限できます。このメモリを使用するドライバー/デバイスは、再起動後も存続するトレース ポイントを保存するように記述できます。カーネルの起動時にウォッチドッグリセットが検出されると、空きメモリのリング バッファがダンプされます。memmap=
mem=
問題が反復可能である場合、またはイベントを反復可能にする方法を発見する場合は、オン コンテキスト スイッチを実行できるスレッド通知機能を登録することも役立ちます。printk
ロックアップにつながる一連のイベントを特定したら、スコープまたはロジック アナライザーを使用して最終的な診断を行うことができます。または、この時点でどのペリフェラルが問題であるかが明らかな場合もあります。
panic=-1
およびreboot=...
をカーネル コマンド ラインで設定することもできます。コードの問題だけがある場合は、kdump機能が役立ちます。
関連: kernel trap (at web archive) . このリンクは利用できなくなった可能性がありますが、この回答にとって重要ではありません。