3、CPU核心故障诊断：核心挂起、指令执行异常、缓存一致性错误的定位与排查

各位工程师，咱们今天聊点硬核的。CPU核心出问题，说白了就是服务器的大脑在抽风。我干了十几年服务器硬件调试，见过最头疼的就是核心挂起和缓存一致性错误。这类问题不像内存报错那么直白，它往往藏得很深，需要你一层层剥开来看。

我个人习惯把核心故障分成三类：核心挂起、指令执行异常、缓存一致性错误。这三类问题有时候会相互关联，但排查思路完全不同。咱们一个一个来拆解。

3.1 核心挂起：CPU核心突然“死机”了

核心挂起，就是某个核心突然不响应任何指令了。你敲命令它没反应，系统调度也切不过去。嗯，这里要注意，核心挂起和系统死机是两码事。系统可能还在跑，但某个核心已经“罢工”了。

核心挂起的典型现象：

  • 系统日志里出现“soft lockup”或“hard lockup”错误
  • top命令看到某个核心的CPU使用率卡在100%不动
  • 中断请求（IRQ）在该核心上堆积，无法处理

排查步骤：

  1. 先确认是不是真的挂起
    用 cat /proc/cpuinfo | grep processor 看看核心数量对不对。再用 mpstat -P ALL 1 观察每个核心的负载。如果某个核心的%idle一直为0，%system也异常高，那基本可以判定挂起了。
  2. 检查中断分布
    我遇到过一种情况：某个核心被大量中断淹没，导致无法处理正常任务。用 cat /proc/interrupts 看看中断在各个核心上的分布。如果某个核心的中断数异常高，可以手动绑定中断到其他核心。
  3. 查看NMI（非屏蔽中断）信息
    这是我最常用的手段。触发NMI可以强制让挂起的核心输出当前状态。在Linux下执行：
echo c > /proc/sysrq-trigger
dmesg | tail -50

你会看到每个核心的寄存器状态、堆栈回溯。如果某个核心的PC指针卡在一个循环里，或者停在某个锁上，那问题就清晰了。

避坑指南： 我曾经遇到一个案例，核心挂起是因为L1缓存中的一条指令被错误地预取了。表面上看是核心死锁，实际上是微架构层面的bug。所以别只看软件堆栈，必要时得查芯片的勘误表。

3.2 指令执行异常：CPU算错了结果

指令执行异常比核心挂起更隐蔽。系统还在跑，但算出来的结果是错的。你想想看，这有多可怕？数据库的查询结果、科学计算的中间值，可能都是错的。

常见表现：

  • 同样的计算，每次结果不一样
  • 浮点运算结果出现NaN或Infinity
  • 程序莫名其妙地segfault，但代码逻辑没问题

定位方法：

我个人习惯先做“二分法”测试。写一个简单的循环，让每个核心执行相同的浮点运算，然后比对结果。代码大概长这样：

#include <stdio.h>
#include <pthread.h>

void* test_core(void* arg) {
    int core_id = *(int*)arg;
    double a = 3.141592653589793;
    double b = 2.718281828459045;
    double result = a * b;
    // 这里可以换成更复杂的运算
    printf("Core %d: result = %.15f\n", core_id, result);
    return NULL;
}

如果某个核心的结果和其他核心不一样，那基本可以断定这个核心的运算单元有问题。嗯，这里要注意，得排除编译器优化导致的差异，建议用 -O0 编译。

警告： 指令执行异常有时候是电压或温度引起的。我见过一个案例，某个核心在低温下工作正常，温度一高就开始算错。所以排查时一定要监控核心温度和电压，用 sensors 命令或者直接读MSR寄存器。

3.3 缓存一致性错误：多核心之间的“数据打架”

缓存一致性错误，说白了就是两个核心对同一块内存的数据看法不一致。核心A说“这个变量是1”，核心B说“不对，我看到的明明是2”。

这类问题在调试时最让人头疼，因为它不是每次都复现。你重启一下可能就好了，但过几天又冒出来。

典型症状：

  • 多线程程序出现不可解释的数据竞争
  • 使用原子操作（如CAS）时，结果不符合预期
  • 系统日志里出现“cache coherency error”或“MCE”信息

排查手段：

  1. 检查MCE（Machine Check Exception）日志
    用 mcelog --client 查看。如果看到“CACHE”或“BUS”相关的错误，那基本就是缓存一致性问题。
  2. 使用性能计数器
    现代CPU都有缓存一致性相关的性能计数器。比如Intel的 MEM_LOAD_UOPS_RETIRED.L3_HIT 和 MEM_LOAD_UOPS_RETIRED.L3_MISS。如果某个核心的L3 miss率异常高，可能说明它的缓存行被其他核心频繁无效化了。
  3. 写一个压力测试
    让多个核心频繁读写同一块内存，观察是否触发错误。代码示例：
// 多线程共享变量
volatile int shared_var = 0;

void* writer(void* arg) {
    for (int i = 0; i < 1000000; i++) {
        shared_var = i;
        // 加内存屏障，强制刷新缓存
        __sync_synchronize();
    }
    return NULL;
}

void* reader(void* arg) {
    int last_val = 0;
    for (int i = 0; i < 1000000; i++) {
        int val = shared_var;
        if (val < last_val) {
            printf("Cache coherency issue detected!\n");
        }
        last_val = val;
    }
    return NULL;
}

关键点： 缓存一致性错误往往是硬件设计缺陷导致的。我遇到过一款芯片，它的L3缓存目录表在特定访问模式下会丢失条目，导致缓存行被错误地标记为无效。这种问题只能通过更新微码或更换芯片来解决。

3.4 综合排查流程

说了这么多，咱们总结一下。遇到CPU核心故障，我建议按这个顺序来：

步骤 操作 工具/命令
1 确认核心状态 mpstat, /proc/cpuinfo
2 检查系统日志 dmesg, /var/log/messages
3 触发NMI获取寄存器快照 sysrq-trigger
4 运行核心一致性测试 自行编写的测试程序
5 检查MCE和性能计数器 mcelog, perf stat
6 查阅芯片勘误表 厂商文档

个人经验： 我调试过一款服务器芯片，它的核心挂起问题其实是内存控制器导致的。核心本身没问题，但内存请求被卡住了，核心只能一直等。所以别只盯着核心看，整个内存子系统的状态也要检查。

最后说一句，CPU核心故障的排查，说白了就是“大胆假设，小心求证”。别怕问题复杂，一步步来，总能找到根因。嗯，今天就聊到这儿，下次咱们讲内存故障诊断。

← 上一章 📖 返回目录 下一章 →