Linux系统崩溃分析需分用户态和内核态两层：用户态用coredump+gdb，内核态必须用kdump+crash；确认coredump启用需检查ulimit -c非零、core_pattern路径可写且持久化；kdump生效需三要素齐备：/proc/cmdline含crashkernel参数、/sys/kernel/kexec_crash_size非零、/proc/meminfo有CrashKernel行。
Linux 系统崩溃分析不是配一个工具就能用的，而是要分两层：用户态进程崩溃用 coredump + gdb，内核态崩溃必须靠 kdump + crash。两者配置逻辑、依赖项、验证方式完全不同，混用或只配一半，等于没配。
怎么确认系统是否已启用用户态 core dump
很多开发者以为程序 segfault 了就该有 core 文件，结果查遍 /tmp 和 /var/tmp 都找不到——大概率是根本没开。
- 运行
ulimit -c，输出为0表示禁用；非零值（如unlimited）才表示允许生成 -
cat /proc/sys/kernel/core_pattern查看保存路径和命名规则，常见错误是路径不存在或无写权限（比如指向/var/coredumps却没创建目录或没chmod 777） - 即使
ulimit -c unlimited临时生效，重启后失效；永久生效需写入/etc/security/limits.conf（如* soft core unlimited），而非仅改~/.bashrc - 某些发行版（如 RHEL 8+）默认启用了
systemd-coredump，此时 core 不落地为文件，而是由systemd-coredump服务接管，需用coredumpctl list或coredumpctl debug <binary>查看
kdump 服务是否真在工作，不能只看 systemctl status
systemctl status kdump 显示 active 并不等于能捕获 vmcore。真正关键的是 crashkernel 内存是否预留成功、捕获内核是否加载进内存。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 检查
cat /proc/cmdline | grep crashkernel，必须看到类似crashkernel=256M或crashkernel=auto；crashkernel=auto在内存 - 运行
cat /sys/kernel/kexec_crash_size，返回值应是非零整数（单位字节），比如268435456对应 256MB；返回0就说明内核启动时根本没预留 - 执行
kdumpctl status（若存在），输出必须是Kdump is operational.；若报错或提示未就绪，大概率是 initramfs 缺少 kdump 模块 - 升级内核后必须手动重建 kdump initramfs：
kdumpctl force-rebuild或dracut -f --regenerate-all，否则新内核下 kdump 会静默失败
用 crash 分析 vmcore 时找不到符号或报版本不匹配
crash 工具本身不带调试信息，它完全依赖你提供的 vmlinux 文件。这个文件不是 /boot/vmlinuz-$(uname -r)，而是带完整符号表的未压缩内核镜像。
- Debian/Ubuntu：安装
linux-image-$(uname -r)-dbg包，vmlinux通常在/usr/lib/debug/boot/vmlinux-$(uname -r) - RHEL/CentOS：安装
kernel-debuginfo-$(uname -r)，vmlinux位于/usr/lib/debug/lib/modules/$(uname -r)/vmlinux - 务必确认
vmlinux和vmcore来自同一内核版本（uname -r输出一致），哪怕只差一个补丁号，符号偏移都可能错位 - 如果
crash /path/to/vmlinux /var/crash/vmcore启动后提示no debugging symbols found，先用file /path/to/vmlinux确认是否含debug字样，再检查该文件是否可读、是否被 SELinux 拦截
手动触发崩溃测试前必须打开 sysrq
想用 echo c > /proc/sysrq-trigger 测试 kdump 是否生效？先确认 sysrq 开关已打开，否则这条命令什么都不会发生。
- 运行
cat /proc/sys/kernel/sysrq，输出必须是1（或至少包含 bit 4，即允许c命令）；若为0，需执行echo 1 > /proc/sys/kernel/sysrq - 该设置默认不持久，重启即失效；如需永久开启，写入
/etc/sysctl.conf：kernel.sysrq = 1，然后sysctl -p - 触发后系统会硬重启，vmcore 生成位置由
/etc/kdump.conf中的path决定，但注意：若该路径挂载在 LVM 或加密卷上，kdump 可能无法访问——测试阶段建议直接设为path /或裸设备路径（如ext4:/dev/sda1）
最常被跳过的环节是验证 crashkernel 是否真正预留成功，以及 vmlinux 文件是否真的匹配且可读。这两点出问题，后续所有分析动作都是空转。
