如何在 Linux 内核中调试页面错误答案

【问题标题】：How to debug Page Faults in the Linux Kernel如何在 Linux 内核中调试页面错误
【发布时间】：2011-08-23 20:15:53
【问题描述】：

目前我在重启时遇到了一些丑陋的内核 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 中的相同。

【问题讨论】：

标签： linux debugging kernel powerpc

【解决方案1】：

请注意，DAR 中的值看起来有点像 ASCII 字符串的片段。实际上，它看起来与GPR03、0x6E615C5D == "na\]" 中的值相比偏移了 24。

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

【讨论】：

【解决方案2】：

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

【讨论】：

是的，但是在最后一个 OOPS 中，我得到了 NIP 中的地址指向 do_page_fault，因此我对我毫无意义。但是我会检查 NIP 的内容以备下次 OOPS 使用并进行拆卸。
你说得对，我搞混了，BDM/GDB 中的当前 nip 指向 do_page_fault，但 *regs 中保存的状态指向崩溃前的状态，谢谢。