ハングプロセス用のカーネルデバッグ？

Question

他の タスクがハングするようなデバイスドライバをデバッグしようとしています。どのタスクがいつ実行されるかは確定的です。 がハングします。

基本的に、「タスクは が120秒以上ブロックされています」というカーネルのエラーメッセージがスタックトレースとともに表示されます。 ハングタスクは「 。そして、スタックトレース内の一番上の機能が異なる 『（カーネルスレッドをpdflushするmkfsのためにsendmailの異なる『mark_locks_held 『に』 bio_submit』に 』 getnstimeofday。

私はハードを持っています の問題を見つけるのは非常に難しいため、これをデバッグするのは非常に難しいので、カーネルが提供するスタックトレースはあまり役に立ちません これらのスタックトレースによれば、それらのプロセスのうちのいくつかはロックを取得しようとしていませんgetnstimeofday 関数）、なぜ彼らがハングするのかわかりません。

だから私は誰かがそのような 問題をデバッグする方法に関するアイデア。 kgdbはここでは役に立ちますか？おそらく、私にちょうど がプロセスがハングアップしていることを教えてくれています。それはどのようなロックが待っていますか？

ご迷惑をおかけして申し訳ございません。

Answer 1

カーネルでフレームポインタを有効にしていない場合、スタックトレースは信頼できず、混乱します。カーネルは、スタック全体を走査して、カーネルコードへのポインタである可能性のある値（潜在的リターンアドレス）を探す。これは、すでに返されている過去の関数呼び出しが依然として印刷されている可能性があることを意味します。

あなたはこのように見えたコードがあった場合：

void A(void) { 
    printk("foo\n"); 
} 

void B(void) { 
    int x; 
    A(); 
} 

void crash(void) { 
    char buf[32]; 
    *(int*)0 = 0; 
} 

void trouble(void) { 
    int x; 
    B(); 
    crash(); 
} 

をあなたのスタックダンプのようなもの表示されることがあります。

：あなたの問題をデバッグする方法については

printk 
A 
crash 
foo 
trouble 
... 

を、私は2つの提案があります

1. デバッグ出力の一部が不良であることが分かっているので、コードに関する知識を使い、 realコールスタック。複数のスタックダンプに共通する機能を探すのに役立つかもしれません。

2. フレームポインタを使用するようにカーネルを再コンパイルします。

カーネルは戻り値のように見えるすべての値を出力しますが、信頼できないアドレスには "？"を付けてフラグを付けます。したがって、スタックダンプは次のようになります。

? printk 
? A 
crash 
? foo 
trouble