保姆级教程：在D1开发板上调试Linux MMU页错误（Page Fault）的实战记录

在D1开发板上调试Linux MMU页错误的实战指南

当你在全志D1开发板上进行底层开发时，突然遇到一个神秘的页错误（Page Fault）异常，控制台打印出一串难以理解的错误信息，整个系统陷入停滞状态。这种场景对于从事嵌入式Linux开发的工程师来说并不陌生。本文将带你深入剖析一个真实的页错误案例，从异常触发到最终修复，手把手教你如何应对这类问题。

1. 理解RISC-V MMU基础架构

在开始调试之前，我们需要先掌握C906处理器上MMU的基本工作原理。与常见的x86架构不同，RISC-V采用了更为简洁的设计理念。

1.1 C906的MMU模式选择

C906处理器支持两种MMU模式：

• Bare模式（SATP.Mode=0）：完全禁用地址转换，物理地址直接作为虚拟地址使用
• Sv39模式（SATP.Mode=8）：采用三级页表转换的39位虚拟地址空间

// SATP寄存器格式示例（C906） #define SATP_MODE_BARE 0 #define SATP_MODE_SV39 8 struct satp_reg { uint64_t ppn : 44; // 物理页号 uint64_t asid : 16; // 地址空间ID uint64_t mode : 4; // 模式选择 };

注意：C906不支持Sv48/Sv57等更大的地址空间模式，这与x86_64架构有明显区别

1.2 三级页表结构解析

Sv39模式下，虚拟地址被划分为多个字段，用于索引不同级别的页表：

39位虚拟地址布局： | 63-39 | 38-30 | 29-21 | 20-12 | 11-0 | | 符号扩展 | PGD索引 | PMD索引 | PTE索引 | 页内偏移 |

每级页表的关键特征对比：

2. 页错误异常现场分析

当系统触发页错误时，首要任务是收集完整的异常现场信息。以下是一个典型的调试流程：

2.1 异常信息收集

在控制台看到的页错误信息通常包含：

[ 123.456789] Oops: 00000000 [ 123.456790] epc : ffffffff80123456 ra : ffffffff80123890 [ 123.456791] sp : ffffffe012345678 gp : ffffffff801abcde [ 123.456792] tp : ffffffe012345678 t0 : 0000000000000000 [ 123.456793] t1 : 0000000000000001 t2 : 0000000000000000 [ 123.456794] s0 : ffffffe012345678 s1 : 0000000000000000 [ 123.456795] a0 : 0000000000000000 a1 : 0000000000000000 [ 123.456796] a2 : 0000000000000000 a3 : 0000000000000000 [ 123.456797] a4 : 0000000000000000 a5 : 0000000000000000 [ 123.456798] a6 : 0000000000000000 a7 : 0000000000000000 [ 123.456799] s2 : 0000000000000000 s3 : 0000000000000000 [ 123.456800] s4 : 0000000000000000 s5 : 0000000000000000 [ 123.456801] s6 : 0000000000000000 s7 : 0000000000000000 [ 123.456802] s8 : 0000000000000000 s9 : 0000000000000000 [ 123.456803] s10: 0000000000000000 s11: 0000000000000000 [ 123.456804] t3 : 0000000000000000 t4 : 0000000000000000 [ 123.456805] t5 : 0000000000000000 t6 : 0000000000000000 [ 123.456806] status: 0000000000000000 badaddr: ffffffc012345678 [ 123.456807] cause: 000000000000000d (Load page fault) [ 123.456808] CPU: 0 PID: 123 Comm: test_proc Not tainted 5.4.61 #1

关键信息提取：

• epc：异常发生时程序计数器值
• badaddr：触发异常的虚拟地址
• cause：异常原因（Load/Store/Instruction page fault）
• status：处理器状态寄存器值

2.2 关键寄存器检查

使用GDB或JTAG调试器检查关键寄存器状态：

(gdb) info registers satp sATP 0x8000000000084008 # Sv39模式，ASID=8，PPN=0x84008 (gdb) x /8gx 0x84008000 # 查看PGD页表内容 0x84008000: 0x8000000000085003 0x0000000000000000 0x84008010: 0x0000000000000000 0x8000000000086003

寄存器解析要点：

1. SATP.Mode=8确认处于Sv39模式
2. PPN字段指向PGD页表物理地址
3. 每个页表项8字节，包含下一级页表的物理地址和权限位

3. 页表遍历与错误定位

有了异常地址和页表基址后，我们需要手动遍历页表来定位问题。

3.1 页表遍历步骤

以虚拟地址0xffffffc012345678为例：

1. 提取各级索引：

   vaddr = 0xffffffc012345678; pgd_index = (vaddr >> 30) & 0x1FF; // 0x100 pmd_index = (vaddr >> 21) & 0x1FF; // 0x091 pte_index = (vaddr >> 12) & 0x1FF; // 0x234

2. PGD表查询：

   (gdb) x /8gx 0x84008000 + (0x100 * 8) 0x84008800: 0x8000000000087003 # PMD表物理地址0x87000

3. PMD表查询：

   (gdb) x /8gx 0x87000 + (0x91 * 8) 0x870488: 0x0000000000000000 # 无效的PTE表指针！

关键发现：PMD表中对应表项为0，表示PTE表不存在，这就是触发页错误的原因

3.2 常见页错误原因分析

根据实践经验，页错误通常由以下原因引起：

在本案例中，PMD表项为空，说明内核未正确建立中间页表。这通常发生在：

• 动态内存映射未完全初始化
• 内存回收后未重建映射
• 驱动程序错误修改了页表

4. 问题修复与验证

定位到问题根源后，我们需要实施修复并验证解决方案。

4.1 修复方案实施

针对缺失PMD表项的情况，修复步骤包括：

1. 分配新的PTE页：

   pte_page = get_zeroed_page(GFP_KERNEL); set_pte_ext(pte_page, __pgprot(_PAGE_TABLE));

2. 更新PMD表项：

   pmd_val = pte_pfn(pte_page) << PAGE_SHIFT | _PAGE_TABLE; set_pmd(pmd_offset(pgd, vaddr), __pmd(pmd_val));

3. 刷新TLB：

   flush_tlb_kernel_range(vaddr, vaddr + PAGE_SIZE);

4.2 修复验证方法

为确保修复有效，建议采用以下验证流程：

1. 内存访问测试：

   echo 1 > /proc/test_page

2. 页表状态检查：

   cat /sys/kernel/debug/page_tables | grep -A 5 ffffffc012345678

3. 压力测试：

   stress-ng --vm 4 --vm-bytes 1G --timeout 60s

5. 高级调试技巧

除了基本页表遍历外，资深开发者还需要掌握以下高级调试技术。

5.1 利用KFENCE捕获内存错误

KFENCE是Linux内核的内存错误检测工具，特别适合捕捉偶发页错误：

// 内核配置 CONFIG_KFENCE=y CONFIG_KFENCE_SAMPLE_INTERVAL=100 // 每100ms采样一次 // 启动参数 kfence.sample_interval=100

KFENCE检测到错误时会打印详细堆栈：

[ 123.456] KFENCE: Out-of-bounds access at 0xffffffc012345678 [ 123.456] test_proc+0x123/0x456 [ 123.456] do_syscall+0x123/0x456

5.2 使用Tracepoint跟踪MMU操作

内核提供了多个MMU相关的tracepoint：

# 启用页表操作跟踪 echo 1 > /sys/kernel/debug/tracing/events/mm/mm_page_table_free/enable echo 1 > /sys/kernel/debug/tracing/events/mm/mm_page_table_alloc/enable # 查看跟踪结果 cat /sys/kernel/debug/tracing/trace_pipe

典型输出示例：

test_proc-123 [000] ...1 123.456789: mm_page_table_alloc: pte=0x87000 order=0 test_proc-123 [000] ...1 123.456790: mm_page_table_free: pte=0x87000 order=0

5.3 性能优化建议

在调试过程中发现的一些性能优化点：

1. 大页使用：

   // 配置1GB大页 madvise(addr, size, MADV_HUGEPAGE);

2. TLB优化：

   // 批量刷新TLB flush_tlb_mm_range(mm, start, end, PAGE_SIZE);

3. 页表缓存：

   # 查看页表缓存统计 cat /proc/vmstat | grep pgtable