1. 课程导论：嵌入式系统故障概述、内核panic与Oops的定义与区别、课程目标与学习路径

1.1 嵌入式系统故障的本质与挑战

嵌入式系统运行在资源受限、实时性要求高的环境中，其故障模式与通用计算机系统有显著差异。故障不仅源于软件逻辑错误，还常由硬件外设异常、内存访问越界、中断冲突、电源波动等因素触发。在嵌入式Linux环境中，内核态故障往往直接导致系统崩溃或功能瘫痪，排查难度远高于用户态程序崩溃。

下表总结了嵌入式系统常见故障类型及其典型表现：

1.2 内核panic与Oops的定义与区别

在嵌入式Linux内核中，panic和Oops是两种最严重的内核态故障响应机制。理解它们的定义和区别是故障排查的第一步。

1.2.1 内核panic

当内核检测到不可恢复的致命错误时，会调用 panic() 函数。此时系统立即停止所有执行，打印错误信息后进入死循环或触发硬件复位。panic通常意味着内核元数据损坏、关键数据结构不一致或硬件严重故障。

1.2.2 内核Oops

Oops是内核在遇到非致命错误时的响应方式。内核会打印错误现场信息（寄存器、堆栈、指令指针等），但尝试继续运行。然而，Oops往往导致当前进程被杀死，系统可能进入不稳定状态。在嵌入式场景中，Oops是更常见的故障形式，因为它允许系统在部分功能失效时维持基本运行。

下表从多个维度对比panic与Oops：

下面的SVG图展示了从故障发生到panic/Oops响应的完整流程：

1.3 课程目标与学习路径

本课程旨在培养学员系统化排查嵌入式Linux内核故障的能力，从理论到实践覆盖完整知识体系。

1.3.1 课程核心目标

• 理解内核故障机制：掌握panic/Oops的触发条件、信息结构、内核行为。
• 掌握调试工具链：熟练使用kdump、crash、GDB、trace32等工具进行现场分析。
• 培养系统化排查思维：从Oops信息提取关键线索，结合源码与硬件手册定位根因。
• 实战驱动修复：通过真实嵌入式故障案例，完成从分析到补丁验证的完整闭环。

1.3.2 学习路径与章节规划

课程分为四个阶段，逐步深入：

下面的SVG图展示了课程学习路径的层次结构：

1.4 学习准备与前置知识

为获得最佳学习效果，建议学员具备以下基础：

• 熟悉C语言编程，理解指针、内存布局、函数调用栈。
• 了解Linux内核基本架构：进程调度、内存管理、中断处理。
• 具备嵌入式开发板（如ARM Cortex-A系列）的基本操作经验。
• 掌握基本的Linux命令行操作和交叉编译工具链使用。

1.5 本章小结