1. 为什么需要内核崩溃日志捕获搞嵌入式开发的兄弟应该都遇到过这种情况设备跑着跑着突然死机重启后一脸懵逼——刚才到底发生了什么特别是像RK3588这样的高性能处理器一旦内核崩溃如果没有可靠的日志捕获机制调试起来简直就像在黑暗中摸象。我去年就踩过这个坑。当时给客户调试一个RK3588的视频处理设备连续运行三天后突然挂掉。重启后查看常规日志啥关键信息都没有。最后只能加printk大法又熬了两个通宵才定位到问题。要是早点用上pstore和ramoops至少能省下30%的调试时间。pstorePersistent Storage是Linux内核提供的一个持久化存储子系统它能在系统崩溃时保存关键日志。而ramoops则是pstore的一个具体实现利用预留的内存区域来存储崩溃信息。这对组合最大的优势是不依赖外部存储设备即使文件系统挂掉也能工作支持多种日志类型dmesg、console、ftrace等2. RK3588上的pstore配置实战2.1 内核配置修改首先得确保内核支持相关功能。我用的是RK3588的Linux 5.10内核配置步骤如下make menuconfig找到这些关键选项Device Drivers --- [*] Persistent store support [*] Log kernel console messages [*] Log user space messages [*] Log panic/oops to a RAM buffer (3) Panic timeout in seconds (NEW)更直接的方法是修改defconfig文件添加以下配置CONFIG_PSTOREy CONFIG_PSTORE_CONSOLEy CONFIG_PSTORE_PMSGy CONFIG_PSTORE_RAMy CONFIG_PANIC_TIMEOUT3这里有个实用技巧CONFIG_PANIC_TIMEOUT3表示系统崩溃后等待3秒再重启。时间太短可能来不及保存日志太长又影响设备自恢复。经过多次测试3秒是个比较稳妥的值。2.2 设备树配置接下来要在设备树中预留ramoops的内存区域。打开rk3588-linux.dtsi添加ramoops: ramoops110000 { compatible ramoops; reg 0x0 0x110000 0x0 0xf0000; record-size 0x20000; console-size 0x80000; ftrace-size 0x00000; pmsg-size 0x50000; };参数解释reg内存区域起始地址0x110000大小0xf0000约960KBrecord-sizeoops/panic日志大小console-size控制台日志大小pmsg-size用户空间消息大小这里有个坑要注意内存地址不能和其他区域冲突。建议先用cat /proc/iomem查看内存使用情况。3. 触发测试与日志提取3.1 手动触发崩溃配置好后可以用这个命令模拟内核崩溃echo c /proc/sysrq-trigger系统会立即触发panic3秒后自动重启。这个测试我在开发板上跑了十几次稳得很。3.2 日志存放位置不同系统存放位置可能不同常见的有Ubuntu/Debian:/var/lib/systemd/pstore/Android:/sys/fs/pstore/其他系统可能直接挂载到/mnt/pstore可以用这个命令查找find / -name *ramoops* 2/dev/null找到的日志文件通常是这样的命名格式dmesg-ramoops-0 console-ramoops-03.3 日志分析技巧拿到日志后先用dmesg查看dmesg -wH --coloralways | less -R重点看崩溃前的最后几条日志。如果日志不完整可以调整console-size参数增大缓冲区。我遇到过一个典型问题视频解码时触发空指针异常。从ramoops日志中直接看到了调用栈[ 4563.721234] Unable to handle kernel NULL pointer dereference [ 4563.721567] Call trace: [ 4563.721789] rk_vcodec_dec_run0x128/0x230 [ 4563.722012] rkvdec2_worker0x64/0x100这比盲目猜测高效多了。4. 高级调试技巧4.1 多日志类型配置除了基本的dmesg还可以配置更多日志类型ftrace-size 0x40000; // 增加ftrace支持 pmsg-size 0x30000; // 用户空间日志需要对应的内核配置CONFIG_PSTORE_FTRACEy CONFIG_PSTORE_PMSGy4.2 自动上传日志对于量产设备可以写个systemd服务自动上传崩溃日志[Unit] DescriptionUpload panic logs Afterpstore.service [Service] Typeoneshot ExecStart/usr/bin/curl -F file/var/lib/systemd/pstore/dmesg-ramoops-0 http://log-server/upload [Install] WantedBymulti-user.target4.3 内存不足处理如果遇到日志丢失可能是内存不足。可以通过dmesg | grep ramoops查看实际分配情况。我建议预留至少1MB空间reg 0x0 0x200000 0x0 0x100000; // 1MB空间5. 常见问题排查问题1配置后看不到日志文件检查内核是否真的panic过cat /proc/cmdline看是否有panic参数确认文件系统有写入权限检查内存区域是否被其他驱动占用问题2日志不完整增大record-size和console-size检查是否有early panic在内核完全初始化前崩溃问题3系统无法自动重启确认CONFIG_PANIC_TIMEOUT设置正确检查硬件看门狗配置记得第一次调试时我忘了开看门狗结果设备死机后就一直卡着。后来加了硬件看门狗软件panic超时双重保障才放心。这套方案在RK3588上跑了半年多捕获了不下20次崩溃日志帮团队节省了大量调试时间。现在只要是Linux项目我都会第一时间把pstore配置好——毕竟谁也不知道崩溃和明天哪个先来。
RK3588内核崩溃日志捕获:pstore与ramoops实战解析
发布时间:2026/6/21 9:59:05
1. 为什么需要内核崩溃日志捕获搞嵌入式开发的兄弟应该都遇到过这种情况设备跑着跑着突然死机重启后一脸懵逼——刚才到底发生了什么特别是像RK3588这样的高性能处理器一旦内核崩溃如果没有可靠的日志捕获机制调试起来简直就像在黑暗中摸象。我去年就踩过这个坑。当时给客户调试一个RK3588的视频处理设备连续运行三天后突然挂掉。重启后查看常规日志啥关键信息都没有。最后只能加printk大法又熬了两个通宵才定位到问题。要是早点用上pstore和ramoops至少能省下30%的调试时间。pstorePersistent Storage是Linux内核提供的一个持久化存储子系统它能在系统崩溃时保存关键日志。而ramoops则是pstore的一个具体实现利用预留的内存区域来存储崩溃信息。这对组合最大的优势是不依赖外部存储设备即使文件系统挂掉也能工作支持多种日志类型dmesg、console、ftrace等2. RK3588上的pstore配置实战2.1 内核配置修改首先得确保内核支持相关功能。我用的是RK3588的Linux 5.10内核配置步骤如下make menuconfig找到这些关键选项Device Drivers --- [*] Persistent store support [*] Log kernel console messages [*] Log user space messages [*] Log panic/oops to a RAM buffer (3) Panic timeout in seconds (NEW)更直接的方法是修改defconfig文件添加以下配置CONFIG_PSTOREy CONFIG_PSTORE_CONSOLEy CONFIG_PSTORE_PMSGy CONFIG_PSTORE_RAMy CONFIG_PANIC_TIMEOUT3这里有个实用技巧CONFIG_PANIC_TIMEOUT3表示系统崩溃后等待3秒再重启。时间太短可能来不及保存日志太长又影响设备自恢复。经过多次测试3秒是个比较稳妥的值。2.2 设备树配置接下来要在设备树中预留ramoops的内存区域。打开rk3588-linux.dtsi添加ramoops: ramoops110000 { compatible ramoops; reg 0x0 0x110000 0x0 0xf0000; record-size 0x20000; console-size 0x80000; ftrace-size 0x00000; pmsg-size 0x50000; };参数解释reg内存区域起始地址0x110000大小0xf0000约960KBrecord-sizeoops/panic日志大小console-size控制台日志大小pmsg-size用户空间消息大小这里有个坑要注意内存地址不能和其他区域冲突。建议先用cat /proc/iomem查看内存使用情况。3. 触发测试与日志提取3.1 手动触发崩溃配置好后可以用这个命令模拟内核崩溃echo c /proc/sysrq-trigger系统会立即触发panic3秒后自动重启。这个测试我在开发板上跑了十几次稳得很。3.2 日志存放位置不同系统存放位置可能不同常见的有Ubuntu/Debian:/var/lib/systemd/pstore/Android:/sys/fs/pstore/其他系统可能直接挂载到/mnt/pstore可以用这个命令查找find / -name *ramoops* 2/dev/null找到的日志文件通常是这样的命名格式dmesg-ramoops-0 console-ramoops-03.3 日志分析技巧拿到日志后先用dmesg查看dmesg -wH --coloralways | less -R重点看崩溃前的最后几条日志。如果日志不完整可以调整console-size参数增大缓冲区。我遇到过一个典型问题视频解码时触发空指针异常。从ramoops日志中直接看到了调用栈[ 4563.721234] Unable to handle kernel NULL pointer dereference [ 4563.721567] Call trace: [ 4563.721789] rk_vcodec_dec_run0x128/0x230 [ 4563.722012] rkvdec2_worker0x64/0x100这比盲目猜测高效多了。4. 高级调试技巧4.1 多日志类型配置除了基本的dmesg还可以配置更多日志类型ftrace-size 0x40000; // 增加ftrace支持 pmsg-size 0x30000; // 用户空间日志需要对应的内核配置CONFIG_PSTORE_FTRACEy CONFIG_PSTORE_PMSGy4.2 自动上传日志对于量产设备可以写个systemd服务自动上传崩溃日志[Unit] DescriptionUpload panic logs Afterpstore.service [Service] Typeoneshot ExecStart/usr/bin/curl -F file/var/lib/systemd/pstore/dmesg-ramoops-0 http://log-server/upload [Install] WantedBymulti-user.target4.3 内存不足处理如果遇到日志丢失可能是内存不足。可以通过dmesg | grep ramoops查看实际分配情况。我建议预留至少1MB空间reg 0x0 0x200000 0x0 0x100000; // 1MB空间5. 常见问题排查问题1配置后看不到日志文件检查内核是否真的panic过cat /proc/cmdline看是否有panic参数确认文件系统有写入权限检查内存区域是否被其他驱动占用问题2日志不完整增大record-size和console-size检查是否有early panic在内核完全初始化前崩溃问题3系统无法自动重启确认CONFIG_PANIC_TIMEOUT设置正确检查硬件看门狗配置记得第一次调试时我忘了开看门狗结果设备死机后就一直卡着。后来加了硬件看门狗软件panic超时双重保障才放心。这套方案在RK3588上跑了半年多捕获了不下20次崩溃日志帮团队节省了大量调试时间。现在只要是Linux项目我都会第一时间把pstore配置好——毕竟谁也不知道崩溃和明天哪个先来。