目前我面临一些丑陋的内核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一样。
答案 0 :(得分：3)
根据定义，如果您在中断上下文中对此地址出现故障，则其中没有任何用处（即，没有必要尝试找出坏指针指向的数据）。您需要反汇编导致NIP（C00302E4）的代码，并查看它获取该地址的位置以及它尝试执行的操作。
答案 1 :(得分：2)
请注意，DAR中的值看起来很像ASCII字符串的片段。实际上，它看起来与GPR03，0x6E615C5D == "na\]"中的值相差24倍。
我怀疑你有一个溢出struct指针的字符串，并且错误指令正在取消引用该结构的成员，该成员位于偏移24处。