前言

服务器运行过程中，PCIe总线错误是最容易被忽视却危害极大的硬件隐患之一。相比硬盘故障或内存错误，PCIe设备的通信故障往往不会立即导致服务崩溃，而是表现为偶发的网络抖动、存储延迟增加或设备降速，严重时才会引发随机重启或数据损坏。PCIe AER（Advanced Error Reporting）机制是Linux内核提供的硬件错误报告接口，正确配置和解读AER日志，是运维人员发现和预防硬件问题的重要技能。

一、PCIe AER基础原理

PCIe设备通过设备状态寄存器（Device Status Register）和链路状态寄存器（Link Status Register）记录错误信息，当错误数量超过阈值后触发中断通知系统。内核的AER模块负责解析这些硬件错误，将其分为可纠正错误（Correctable Error）和不可纠正错误（Uncorrectable Error）两类。

可纠正错误包括：

  • Replay Timer Timeout：事务重传超时，通常由信号完整性问题引起
  • Bad DLLP（Data Link Layer Packet）：链路层数据包校验失败
  • Bad TLP（Transaction Layer Packet）：事务层数据包校验失败
  • Receiver Overflow：接收端缓冲区溢出

不可纠正错误则更为严重，常见类型包括：

  • UR（Unsupported Request）：设备发送了不被目标设备支持的请求
  • CA（Completer Abort）：目标设备主动中止事务
  • Poisoned TLP：数据包标记了错误位，接收方应丢弃
  • ECRC Failure：端到端CRC校验失败

二、确认AER支持状态

首先需要确认内核和硬件平台是否正确支持AER：

1
2
3
4
5
6
7
8
# 检查内核AER支持
dmesg | grep -i aer

# 查看AER能力设备
cat /sys/bus/pci/devices/*/aer_dev_correctable 2>/dev/null | wc -l

# 确认AER stats接口存在
ls /sys/bus/pci/devices/*/aer_*

在支持AER的系统中，每个PCIe设备目录下应有aer_dev_correctable和aer_dev_fatal等文件节点。如果返回为空，说明内核未启用AER支持或硬件平台不具备该能力。

三、实时监控与告警配置

生产环境建议通过mcelog结合系统日志实现自动告警。mcelog是Linux内核用于处理Machine Check Exception的工具，能捕获包括AER错误在内的多种硬件异常。

3.1 安装与配置mcelog

1
2
3
4
5
6
7
8
9
10
11
# CentOS/RHEL
yum install mcelog -y

# Ubuntu/Debian
apt install mcelog -y

# 编辑配置文件 /etc/mcelog/mcelog.conf
daemonize yes
syslog yes
logfile /var/log/mcelog
socket /var/run/mcelog-client.socket

3.2 配置日志轮转

AER错误日志可能快速膨胀，需要配置logrotate：

1
2
3
4
5
6
7
8
9
10
11
# /etc/logrotate.d/mcelog
/var/log/mcelog {
    daily
    rotate 14
    compress
    missingok
    notifempty
    postrotate
        /bin/kill -HUP $(cat /var/run/mcelog.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

3.3 Prometheus + node_exporter监控

可以通过脚本采集AER错误计数并暴露给Prometheus：

1
2
3
4
5
6
7
8
9
10
#!/bin/bash
# aer_metrics.sh — 采集PCIe AER错误计数

for dev in /sys/bus/pci/devices/*/aer_dev_correctable; do
    device=$(dirname "$dev" | xargs basename)
    correctable=$(cat "$dev" 2>/dev/null || echo 0)
    fatal=$(cat "$(dirname "$dev")/aer_dev_fatal" 2>/dev/null || echo 0)
    echo "pcie_aer_correctable_errors{device=\"$device\"} $correctable"
    echo "pcie_aer_fatal_errors{device=\"$device\"} $fatal"
done

四、AER错误诊断与定位

当收到AER告警时，需要快速定位问题设备并评估影响范围。

4.1 查看详细错误日志

1
2
3
4
5
6
7
8
# 读取AER错误计数（不可纠正）
cat /sys/bus/pci/devices/*/aer_dev_fatal

# 查看最近一次错误的详细描述
dmesg | grep -A5 "aer_err"

# 通过lspci获取设备信息
lspci -vvv -s 0000:01:00.0 | grep -i "Device Seri\|AER"

4.2 识别问题设备

PCIe AER错误高发通常由以下原因导致：

原因 症状特征 排查方法
插槽接触不良 错误集中在特定插槽，震动后加剧 重插设备，检查插槽金手指
电源供电不稳 高负载时触发，散热改善后减轻 检查电源模块输出，测量电压波动
PCIe版本不匹配 降级到较低速率运行（Gen3→Gen2） lspci -vv 查看Link Speed/Sta
驱动问题 特定版本驱动触发，更换驱动后消失 尝试更新或回滚驱动
固件bug 厂商已知问题，更新固件可解决 查厂商更新日志

4.3 链路速率降级分析

1
2
3
4
5
6
7
# 查看所有PCIe设备的协商速率
for dev in /sys/bus/pci/devices/*/current_link_speed; do
    device=$(dirname "$dev" | xargs basename)
    speed=$(cat "$dev" 2>/dev/null)
    width=$(cat "$(dirname "$dev")/current_link_width" 2>/dev/null)
    echo "$device: $speed x$width"
done

如果发现设备实际速率低于标称速率（如应支持Gen4 x8但运行在Gen3 x8），且伴随AER错误，基本可以判定存在硬件通信问题。

五、故障处理流程

紧急响应

  1. 记录现场：保存dmesg日志、lspci -vvv输出、设备AER计数
  2. 评估影响：确认AER错误是否影响业务（不可纠正错误需立即处理）
  3. 隔离设备：如可能，将故障设备临时移除或切换到备用路径
  4. 通知相关方：硬件问题通常需要厂商介入，保留证据

根因分析

不可纠正的AER错误通常需要以下步骤：

  • 提取PCIe设备固件版本和驱动版本
  • 检查服务器BMC日志（IPMI SEL）是否有对应记录
  • 对比厂商硬件兼容性列表（HCL）
  • 必要时联系厂商提供AER错误原始数据

结语

PCIe AER监控是服务器硬件运维中容易被忽略但回报率很高的一环。建议在标准化服务器部署时默认启用AER日志采集，配合mcelog和Prometheus构建监控体系，将硬件故障从被动发现转变为主动预防，将故障处理时间窗口从小时级压缩到分钟级。