ARM64架构下Kdump与Crash工具实战指南

1. ARM64架构下Kdump与Crash工具入门指南第一次接触内核崩溃分析的朋友可能会被一堆术语吓到但别担心咱们今天就用最接地气的方式聊聊这个系统医生组合。想象一下你的手机突然死机屏幕上跳出系统异常的提示这时候Kdump就像个急救员迅速把系统崩溃时的现场照片保存下来而Crash工具就是那个拿着放大镜仔细检查照片的侦探。在ARM64架构的设备上比如现在很多手机和服务器用的芯片这套组合拳特别重要。我去年处理过一个真实案例某厂家的智能网关设备在高温环境下频繁重启就是靠Kdump捕获的崩溃日志发现是某个驱动内存泄漏。当时如果没有这个工具可能现在你们家的路由器还在莫名其妙掉线呢。2. 工具准备与编译实战2.1 kexec工具全家桶kexec这玩意儿相当于系统重启的快捷方式传统重启要走BIOS/UEFI这套复杂流程而kexec能直接从一个内核跳转到另一个内核。在ARM64平台上编译时要注意这几个坑# 下载最新源码总有人问为什么要用静态编译后面会解释 wget https://mirrors.edge.kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.26.tar.gz tar xvzf kexec-tools-2.0.26.tar.gz cd kexec-tools-2.0.26 # 关键配置参数踩过坑的都知道交叉编译多痛苦 LDFLAGS-static ./configure \ ARCHarm64 \ --buildx86_64-linux-gnu \ --hostaarch64-linux-gnu \ --targetaarch64-linux-gnu \ --without-xen make -j$(nproc)静态编译主要是为了在崩溃环境里不依赖动态库。去年给某车企做车载系统调试时就遇到过因为动态库版本问题导致kexec无法运行的尴尬情况。2.2 Crash工具编译那些坑Redhat工程师开发的Crash工具堪称内核调试的瑞士军刀但编译时可能会遇到这些幺蛾子# 解决依赖问题Ubuntu/Debian系 sudo apt-get install -y libaio-dev libncurses5-dev zlib1g-dev liblzma-dev flex bison byacc # ARM64专用编译指令 make targetARM64最近帮客户调试RK3588开发板时发现新版的Crash 8.0对ARM64的支持更完善了特别是新增了NEON指令集的反汇编支持。验证编译是否成功可以这样$ ./crash --buildinfo build_target: ARM64 build_version: 8.0.03. 内核配置与内存预留技巧3.1 必须开启的内核选项这几个配置项就像汽车的保险带平时觉得碍事出事时才知道多重要CONFIG_KEXECy CONFIG_SYSFSy CONFIG_DEBUG_INFOy # 这个没开的话调试时会想撞墙 CONFIG_CRASH_DUMPy CONFIG_PROC_VMCOREy最近调试一个5.15内核时发现新版本多了个CONFIG_CRASH_HOTPLUG选项对于支持CPU热插拔的设备特别有用。3.2 内存预留的艺术预留内存就像给救护车留的应急车道太小了不够用太大了浪费。ARM64平台推荐这样设置# 在bootargs里添加1G内存设备示例 crashkernel256M0x1a0000000通过cat /proc/iomem检查是否生效时你会看到类似这样的保留区域1a0000000-1a7ffffff : Crash kernel有个客户曾经设了512M结果还是不够后来发现他们的设备挂了20多个USB设备内核数据结构特别大。所以实际项目中要根据设备负载调整这个值。4. Kdump全流程操作指南4.1 捕获内核加载这个步骤就像给系统安装一个黑匣子kexec -p /boot/Image \ --initrd/boot/initrd.img \ --appendroot/dev/mmcblk0p1 1 maxcpus1 reset_devices关键参数解释maxcpus1只用一个CPU避免并发问题reset_devices让内核知道这是崩溃恢复环境4.2 触发与收集实战测试时别傻乎乎直接拔电源用这个优雅的方式触发echo c /proc/sysrq-trigger收集vmcore的脚本可以这样写带自动归档功能#!/bin/bash DUMP_DIR/var/crash/$(date %Y%m%d) mkdir -p $DUMP_DIR # 自动编号避免覆盖 counter1 while [ -f $DUMP_DIR/vmcore_$counter ]; do ((counter)) done cp /proc/vmcore $DUMP_DIR/vmcore_$counter vmcore-dmesg /proc/vmcore $DUMP_DIR/vmcore-dmesg_$counter.txt5. Crash工具深度解析5.1 分析入门姿势启动Crash就像启动侦探事务所crash vmlinux vmcore第一次看到满屏信息别慌重点关注这几个关键线索PANIC原因示例中的sysrq: SysRq : Trigger a crash崩溃时的CPU编号出问题的进程上面例子是sh5.2 实用命令手册5.2.1 回溯调用栈bt命令就像时间机器能看到崩溃前的函数调用轨迹crash bt -slf # 显示源码位置和局部变量 PID: 641 TASK: ffff8001df128dc0 CPU: 5 COMMAND: sh #0 [8caa7f99223ac900] machine_kexec60 at ffff0000082185ec /arch/arm64/kernel/machine_kexec.c:158 X19: 0000000000000001 X20: 00000000020b54e0 X21: 0000ffff855d2560 X22: 00000000000000025.2.2 内存侦探技巧查看内存就像法医验尸crash rd -a linux_banner # 查看内核版本 ffff000008d40070: Linux version 4.19.661.0.0 crash search -s 0xffff000008000000 -e 0xffff000009000000 BUG: # 搜索特定字符串5.2.3 进程状态分析ps命令的进阶用法crash ps -t 167 # 查看进程运行时间 PID: 167 COMMAND: bst_lw0 RUN TIME: 00:15:01 START TIME: 8177699104 crash ps -p 167 # 查看进程族谱 PID: 0 COMMAND: swapper/0 PID: 2 COMMAND: kthreadd PID: 167 COMMAND: bst_lw06. 实战案例解析去年处理过一个典型故障某智能摄像头设备在夜间频繁重启。用Crash分析vmcore后发现crash bt -t PID: 123 COMMAND: irq/35-cam #0 [ffff8001e450b6a0] __schedule0x320 at ffff0000082b5d20 #1 [ffff8001e450b738] schedule0x7c at ffff0000082b60bc #2 [ffff8001e450b868] schedule_timeout0x1f8 at ffff0000082b9f58 #3 [ffff8001e450b8f8] wait_for_completion0x108 at ffff0000082d3b08 #4 [ffff8001e450b938] camera_power_off0x64 at ffff000009a2b164结合日志发现是某个摄像头模块在低光照条件下电源管理异常最后通过更新驱动解决了问题。这种问题如果不用KdumpCrash可能排查几个月都找不到原因。7. 性能优化与小技巧压缩vmcore在内存紧张的设备上可以这样节省空间makedumpfile -l --message-level 1 -d 31 /proc/vmcore vmcore.compressed自动化分析把常用检查项写成脚本#!/bin/crash -s bt ps -a log -a exit符号调试技巧遇到没有调试符号的情况可以尝试crash sym -m ffff000008000000 # 手动加载符号最近在RK3588平台上测试发现使用5.10以上内核时配合Crash 8.0能更好地解析ARM64的特定寄存器状态特别是当分析NEON相关崩溃时。