カスタマイズされた組み込みLinuxボードを開発中です。Power PCベースのSOCそしてディスプレイパネル。
ビデオの再生中にLinuxカーネルがハングし、sysrq-triggerに応答しない問題をデバッグしています。
有効にするとftrace問題が消えます。また、などのよう
なさまざまなカーネルハッキングオプションを試しましたdebug soft irq。detect hung taskまだ試していないkdbかkgdb試していませんが、この場合役に立つかどうかはわかりません。
Lauterbachの設定が正しく機能しないため、使用できません。 :(
チップベンダーはカーネルとプラットフォームコードを提供しましたが、もはやビジネスをしていないのでサポートはありません：（
方法1
- 応答しないと、
sysrq-trigger割り込みハンドラにかかっていると思われます。 - そこで、職場で（停止前）
/proc/interruptsユースケースに関連する中断を監視して把握しました。その後、セクションにフラグを追加し、noinit各irqハンドラの起動と終了時にそれらを更新しました。以前に印刷したことがあります。request_irq - 問題を再現した後、ハードウェア監視者がシステムを再起動した後にこれらのフラグを表示すると、その
dmesg値がirq_handlers終了したことを示します。 - 私が見たことがないirqの一つはです
timer。しかし、何も見つからない場合は、そこにもフラグトグルを追加します。 （しかしそこには希望はない）
質問セット1
A）カーネルが停止する以外に何が停止する可能性がありますかirq handler？
B）このアプローチを改善するための提案はありますか？
C）他のデバッグ技術がありますか？
方法2
- 以前に異なるファームウェアバージョンをテストした結果、カーネルに関連していない2つの変更（ビデオの再生に関連しないカーネルモジュール、もう1つはカーネルコードの小さな変更）の変更が原因で発生しました。これらの変更を削除すると、カーネルはフリーズします。消え去ります。
- しかし、2つのカーネルの変更のうちの1つが維持され、クラッシュが再び発生した場合、より多くの話があります。
- 私たちはこれらの変更を批判的に調査し、無関係な変更がどのように影響するかを判断します。
質問セット2
A) 上記2番方法の観点からみると、もしかしたら特に疑われる部分がありますか？ （どの質問をすべきかわからないので、この質問をします。）
B）このアプローチをさらに改善するための提案はありますか？