服务器Crashdump分析指南

发表于 分类于
本文系统讲解服务器Crashdump分析的核心知识，涵盖Crashdump简介、RAS技术与错误分类（透明错误、可纠正错误、延迟错误、不可纠正错误、硬件永久性故障）、MCA架构（基本概念、EMCA机制、故障分类）、Intel G40/G50 crashdump文件解析方法、BMC下载crashdump日志步骤、关键日志文件（BAFI_crashdump.json、AssertInformation.dat、idl.log、maintenance.log）及MCE问题分析流程，是服务器硬件故障诊断的实用指南。

服务器Crashdump分析指南

Crashdump简介

Crashdump是服务器硬件故障(如内存、CPU、PCIe设备等)导致机器宕机、死机或触发重启时，服务器带外管理系统抓取的CPU寄存器信息。通过分析这些信息，可以确定导致故障的具体原因。

服务器硬件故障触发CPU的错误检测机制(如Intel的RAS系统)，系统将当前CPU寄存器状态保存为crashdump.json文件，并且自动生成解析文件BAFI_crasdump.json，用于后续分析。

RAS技术与错误分类

RAS技术介绍

RAS(Reliability, Availability, and Serviceability)是现代服务器CPU的关键技术，用于提高系统的可靠性、可用性和可维护性。

错误分类

错误处理流程

  1. 透明错误：已被硬件纠正，上层无需处理
  2. 可纠正错误：标记错误位置，通过RAS技术修复，用户通常不会感知
  3. 延迟错误：标记毒性数据位置，限制传播，避免演变为更严重问题
  4. 不可纠正错误：尝试隔离故障，严重时系统宕机，需通过带外管理软件恢复或重启
  5. 硬件永久性故障：需更换硬件或启用备用设备

RAS系统架构

故障管理系统由多层组件协同工作：

  • HDM(带外管理)：故障定位系统核心，负责收集、汇总和分析故障
  • 处理器平台：增强对处理器、内存、PCIe设备硬件故障的管理能力
  • CPLD：与各硬件模块接口，捕获异常状态，向HDM传递故障信息
  • BIOS：实现CPU、内存、PCIe及存储设备的故障收集和定位
  • 客户界面：通过HDM的Web界面进行远程或本地系统维护
  • 通信协议：包括eSPI、SPI、PCIe、UART、I2C、SMBUS、LocalBus等

MCA架构

x86处理器（1978 年）将原本属于RISC架构（起源于 1981 年）专属的诸如机器校验架构（Machine Check Architecture, MCA）等特性移植了过来。

MCA基本概念

MCA(Machine Check Architecture) 是硬件错误检测和上报机制，通过 MSR(Model Specific Register) 实现检测和记录错误信息，MSR分为两个部分，一部分用来进行设置，另一部分用来描述发生的硬件错误。当CPU检测到不可纠正的MCE（Machine Check Error）时，就会触发Machine Check Exception，通常软件会注册相关的函数来处理这个exception，在这个函数中会通过读取MSR来收集MCE的错误信息，然后重启系统。MCA以bank为单位对错误进行处理，全局相关的寄存器组定义了如何开启MCA的能力。每一个 BANK 则具体对应一类错误源，如 CPU，MEMORY，CACHE，CHIPSET 等等。每一个 BANK 都可以进行单独的控制，这样软件就能够针对每一个 BANK 使用特定的方式进行处理。由于 MCA 以时间窗口为单位对错误进行采样，因此在每一个采样结束时有可能会发现有不止一个的错误产生，但是只会触发一次中断或者异常，因此当软件进行处理时必要要轮询所有的 BANK 以确保每一个产生的错误都可以被处理。

Intel在MCA的基础上又推出了EMCA，简单来讲它可以将MCE和CMCI转换成SMI，让Firmware（BIOS）可以先行处理，然后再丢给OS。AMD也有类似的机制，只是不叫EMCA。

参考链接：服务器RAS性能 - quenby - 博客园

MCA故障分类

Intel G40/G50 crashdump文件解析

环境准备

在Windows 11系统下准备Python环境(如缺少相关库文件，参考Readme说明)

日志解析步骤

  1. 将黑盒日志目录bmcblackinfo\bmcloginfo\log\oemlog\crashdump中的crashdump-xxx.json文件拷贝到cscripts\cscripts\summarizer目录
  2. 在软件所在目录执行：python cd_summarizer.py crashdump-2024.08.22_12.06.23.json

问题定位

在cscripts\cscripts\summarizer目录下查找解析后的文件

BMC下载crashdump日志

cd /var/log
chmod 777 crashdump
./crashdump --dump-now
# 将生成的json文件拷贝出来

关键日志文件

  • BAFI_crashdump_.json：主要解析文件，关注bank信息
  • AssertInformation.dat：查看CPU的PPIN，判断CPU是否更换过
  • idl.log：查看对服务器的操作记录，MCE错误信息，发生时间和位置
  • maintenance.log：当CPU发生Correctable MCERR但未触发ACD时，查看哪个bank报错

crshdump工具可以抓取bmc寄存器信息（首先请确保当前处于caterr状态）

故障分析流程

MCE问题分析步骤

  1. 初步排查：

    • 查看SEL日志中MCE发生前是否有power报错、超温问题、POSTError或内存/PCIe设备报错
    • 如有这类报错，优先解决这些错误

  2. 仅有CorrectableMCERR：

    • 如果只有CorrectableMCERR且没有MCE发生
    • 查看黑匣子的maintenance.log文件，确认是哪个bank报错
    • 或抓取OS日志分析，联系研发进行深入分析

  3. 发生MCE并触发ACD：

    • 如果CPU发生MCE并触发了ACD
    • 查看黑匣子的idl日志，确认哪颗CPU的哪个bank引发MCE，以及发生时间
    • 根据时间戳查找BAFI解析的crashdump日志进行分析

  4. Crashdump分析原则：

    • 确定哪颗CPU先发生MCERR
    • 分析该CPU报错的bank
    • 如果既有core设备报错又有uncore设备报错，先解决uncore问题
    • 如果先报错的CPU只有core报错，而另一颗CPU有uncore报错，优先排除另一颗CPU的uncore问题

📚 参考资料