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 格式，这是由过时的 Kernel 2.4.25 Kernel 生成的，但我认为机制应该与 Kernel 2.6 中的相同。

4

2 回答 2

3

根据定义，如果您在中断上下文中对该地址进行页面错误，则其中没有任何用处（即没有必要尝试找出错误指针指向的数据）。您需要反汇编导致 NIP (C00302E4) 的代码，并查看它从哪里获得该地址以及它试图做什么。

于 2011-05-12T05:49:17.367 回答
2

请注意，in 中的值DAR看起来很像 ASCII 字符串的片段。事实上，它看起来像是从 , 中的值偏移GPR0324 0x6E615C5D == "na\]"。

我怀疑您有一个字符串溢出了一个struct指针，并且错误指令正在取消引用该结构中位于偏移量 24 的成员。

于 2011-05-17T05:21:56.667 回答