目前，我面临着一些丑陋的内核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跟踪发生在高网络负载期间。
我面临的主要问题是mmu异常机制调用了do_page_fault函数，因此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/