pstore转储原因：配置哪些Oops与关机事件会生成记录

作者LIU, ZHUOHUI

“需要保存崩溃日志”还不足以成为验收要求。产品可能需要Panic证据、可继续运行的Oops报告、紧急重启诊断，或正常关机记录；这些事件进入ramoops的条件并不相同。本文按Linux v6.12上游实现，建立可审查的kmsg原因过滤策略，不承诺每次物理复位都产生文件，所列事件矩阵也不代表已完成板级测试。

定义事件路径，而不只记录“重启了”

先问事件是怎样发生的。Oops不一定发展成Panic；配置为Oops后升级成Panic的系统，与继续运行的系统可能具有不同事件序列。紧急重启也不等于正常关机。现场人员说“设备重启了”，描述的是结果，还不能据此确定kmsg转储原因。

v6.12枚举中，UNDEF为0、PANIC为1、OOPS为2、EMERG为3、SHUTDOWN为4，之后是边界值MAX。这是一组有序阈值，不是可独立组合的位标志。复制数字之前应核对产品实际分支，依据见v6.12原因枚举。

区分明确阈值与默认回退规则

kmsg分发器跳过高于转储器最大原因的事件。当最大值为UNDEF时，默认使用OOPS；启用printk.always_kmsg_dump后才改用MAX。因此，明确设为1或2的阈值，不会仅因打开全局参数就自动扩大。依据见kmsg分发实现。

先用文字写策略，再转成数值：“只收Panic”对应1，“收Panic与Oops”对应2。0表示交给全局回退规则决定，并不表示关闭全部转储。尤其在设备树与启动参数由不同团队维护时，应明确谁有权修改这一策略。

实际发出的kmsg原因经过明确阈值或UNDEF回退判断后，才调用已注册的后端
通过过滤只说明具备资格，后端就绪和写入完成仍需单独证明。

检查部署后的配置来源

v6.12设备树绑定中，ramoops的max-reason默认值为2。模块参数写作max_reason，设备树属性则使用连字符。旧的dump_oops与no-dump-oops已经废弃，新配置应优先采用当前字段并审查遗留值。参见ramoops绑定。

# 目标设备上的只读观察
cat /proc/cmdline
cat /sys/module/ramoops/parameters/max_reason
cat /sys/module/printk/parameters/always_kmsg_dump
dmesg | grep -Ei 'ramoops|persistent store'

文件不可见时，记录这一事实并检查保存的发布交付物，不要为了试探接口而写入新值。对照实际设备树、命令行、内核配置和启动信息。驱动会把有效最大原因传递给pstore后端，团队应明确产品究竟使用哪条配置入口。依据见ramoops配置处理。

允许通过，还必须确实调用转储

阈值无法创造没有发出的事件。正常重启、停机和断电的软件实现包含SHUTDOWN转储调用，紧急重启使用EMERG。这只能说明有关内核软件路径的设计，不能证明某块板上的复位按钮或固件复位一定经过这些路径。参见重启与关机实现。

为每个产品事件追踪实际入口，并记录可能的旁路。如果处理器在转储调用之前停止，或后端尚不可用，即使原因符合阈值也没有可用记录。此时应标注“事件路径尚未证明”，不能不断增大max_reason，直到碰巧看到文件才认定修复。

把console证据与dmesg事件记录分开

启用pstore控制台前端后，内核控制台消息可以在没有Oops或Panic时被记录。因此，一个console-ramoops文件不能证明事件通过了dmesg原因过滤；缺少该文件也不能单独证明阈值错误。依据见控制台前端配置。

每项测试都要指定预期记录类型。在受控工作负载中使用唯一测试标识，另行保存事件发生的外部观察，再与下次启动后的证据对应。熟悉的文件名并不够，它可能属于上一次事件，也可能来自另一种前端。

设计能够区分策略的安全矩阵

矩阵建议包含事件入口、发出原因、有效阈值、是否允许、预期记录类型和实际结果。比较阈值1与2时必须安排Oops案例，否则只测Panic无法区分两者。检查全局回退时，固定max_reason=0，再分别观察always_kmsg_dump关闭与开启，不要没有对照地同时修改多个因素。

先完成源码审查和配置只读核对。真正中断系统的事件只能在隔离开发环境执行，并准备批准的恢复方式及可丢弃工作负载。每轮应保存配置快照、触发入口、外部观察和预期记录类型，保证另一位工程师能够解释失败。没有新记录时，先检查事件是否真的发生及身份是否匹配，再讨论过滤规则。正常重启与紧急重启应分成两例；测试前保存已有证据，还要记录Oops是否被配置为升级Panic。意外升级的测试不能证明原先的Oops预期。

也要安排明确的负向预期：被过滤事件不应为该事件生成新的dmesg记录，但仍可能留下console内容。判断前核对事件身份与采集时间。这里不提供破坏性触发命令，因为安全入口取决于实验平台及其授权条件。

交付能解释结果的事件策略

  • 枚举与分发规则对应准确发布内核。
  • 有效阈值和全局回退的作用写清楚。
  • 每个支持事件映射到真实转储调用。
  • console、dmesg及旧记录能够区分。
  • 过滤资格、捕获成功和后续采集分别记录。

最终承诺应是“这些事件路径在这些条件下，预期产生这些类型的记录”。它比笼统认为每次Oops、正常重启和硬件复位都应留下同一种崩溃文件，更适合作为产品支持依据。

类似文章