目前，我在重启时遇到了一些难看的内核 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 中的相同。
最佳答案
根据定义，如果您在中断上下文中在此地址上发生页面错误，则其中没有任何用处(即没有必要尝试找出错误指针指向的数据)。您需要反汇编导致 NIP (C00302E4) 的代码，并查看它从何处获得该地址以及它试图做什么。
关于linux - 如何调试 Linux 内核中的页面错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5973754/