2

現在、再起動でいくつかの醜いカーネル OOPS に直面しています。MPC5200 ベースのカスタム デザインを実行しています。次のような OOPS メッセージが表示されます。

VM: Either in interrupt or mm = NULL. mm=0xc0196520 in interrupt: 1
VM: Access of bad area @0x6e615c75
Oops: kernel access of bad area, sig: 11
NIP: C00302E4 XER: 20000000 LR: C00F15D4 SP: C6207B30 REGS: c6207a80 TRAP: 0300    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 6E615C75, DSISR: 20000000
TASK = c6206000[4778] 'SimpleServer2' Last syscall: 102
last math c6206000 last altivec 00000000
GPR00: 7C74696B C6207B30 C6206000 6E615C5D 00000000 00000000 C01BFE68 00000001
GPR08: F0000500 C7CD1600 FFFFFFE3 C7CD1600 00000001 10152540 10100000 10100000
GPR16: C01B0000 00000000 C6207E48 000016D0 00001032 06207BF0 00000000 C0005CC0
GPR24: C0006DCC C6207EA0 C01B0000 C0190000 C0190000 C01D0000 C56A2220 00000001
Call backtrace:
C0018034 C00F1608 C00F6738 C0017D08 C0006EFC C0005CC0 C6207EA0
C011040C C012FEC4 C00EDC7C C00EF078 C00EF518 C0005A7C 10089C18
1001DFAC 10015660 10000608 10003E68 1000804C 10085A0C 100BC020
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 1 seconds..

これらの OOPS トレースは、ネットワーク負荷が高いときに発生します。私が直面している主な問題は、do_page_fault 関数が mmu 例外メカニズムによって呼び出されるため、gdb 内のスタック コンテキストが信頼できないことです。デバッグしてプリントアウトを追加した後、CPU が割り込みコンテキストにあるように見えることがわかりました。したがって、このエラーは回復できません。

OOPS トレースを理解する限り、oops を引き起こすアドレスは DAR レジスタに格納されています: DAR: 6E615C75。

このアドレスから情報を取得するにはどうすればよいですか? gdb でアドレスを逆アセンブルしようとしましたが、どの関数にもマップされていません。

OOPS 形式について疑問に思っている人がいる場合、これは古いカーネル 2.4.25 カーネルによって生成されますが、メカニズムはカーネル 2.6 と同じである必要があると思います。

4

2 に答える 2

3

定義上、割り込みコンテキストでこのアドレスでページ フォールトが発生した場合、そのアドレスには何の役にも立ちません (つまり、不良ポインタが指すデータを見つけようとしても意味がありません)。NIP (C00302E4) につながるコードを逆アセンブルし、どこでそのアドレスを取得し、何をしようとしているのかを確認する必要があります。

于 2011-05-12T05:49:17.367 に答える
2

DARの値が ASCII 文字列の断片のように見えることに注意してください。GPR03実際、の値から 24 のオフセットのように見えます0x6E615C5D == "na\]"。

ポインターをオーバーフローしている文字列がstructあり、障害のある命令がオフセット 24 にあるその構造体のメンバーを逆参照していると思われます。

于 2011-05-17T05:21:56.667 に答える