长江计算服务器 BMC 日志分析：硬盘、内存、电源、CPU 高温与 DPU/PCIe 故障排查

前言

长江计算部分服务器使用的 BMC ，与华为 openUBMC 生态存在较强关联。

openUBMC 是华为开源的 BMC 相关项目。

实际采集到的 BMC 日志包中，常见有 v0 和 v1 两类目录结构，主要日志都集中在 AppDump 目录下

一般硬件故障看AppDump内的就可以判断

但是有一些涉及系统和软件层面的故障就需要收集系统内日志了

比如：

1. 单依靠 BMC 告警无法判断，但系统内业务异常
2. PCIe 设备掉卡、GPU/DPU/NVMe 识别异常
3. RAID 卡状态异常但 BMC 无法准确定位
4. 服务器异常重启、宕机、panic、MCE、I/O error
5. 硬盘在 BMC 上显示正常，但系统内掉盘或报错
6. CPU 降频、高负载、高温需要结合系统负载判断

v0的告警日志主要看AppDump/sensor_alarm下的

current_event.txt   当前告警
sel.tar/eo_sel.csv  历史告警日志
sensor_info.txt      传感器信息

v1的告警日志主要看AppDump\event下的

current_event.txt   当前告警
eo_sel.csv            历史告警日志
sel.txt                   历史告警日志

此外还有些日志，v0和v1略有不同，但是命名都差不多比如：

• Storage_mgmt：主要与硬盘、RAID、存储管理相关
• pcie：主要与 PCIe 设备、链路、插槽相关
• power、psu、power_mgmt：主要与电源模块、供电状态、电源策略相关

然后就是要分清楚，什么类型的故障需要下电更换，哪些可以热插拔

一般来说：

硬盘、光模块、电源模块 PSU、灵活网卡/可插拔网卡模块

以上这些是可以热插拔的，更换无需断电

注意：是否支持热插拔仍要以具体服务器型号和维护手册为准。

比如硬盘虽然通常支持热插拔，但仍需确认 RAID 状态、业务冗余状态和故障槽位，避免误拔正常盘；PSU 虽然通常支持热插拔，但需要确认另一块电源和供电链路正常。

下面这些必须断电：

内存、CPU、PCIE设备（包括：阵列卡、标准网卡、显卡、Riser卡、DPU卡等）、BBU

---

内存故障分析

AppDump\sensor_alarm下current_event.txt

Event Num  | Event Time                     | Entity Name          | Sensor Name          | Alarm level  | Event Desc
1          | 2026-07-01 Wednesday 20:10:21  | Memory               | DIMM070              | Critical     | DIMM070 triggered an uncorrectable error, (SN:XXXXXXXXXXXXXXXXXX).

这类告警属于不可纠正 ECC 错误，也就是内存已经出现无法通过 ECC 自动修复的错误。

如果只是 Correctable ECC，可能还可以结合频率和次数观察；但 Uncorrectable ECC / UE 通常需要优先更换对应槽位内存。

如果更换了DIMM070槽位的内存，故障仍然存在，需要考虑：

1. 更换的内存条存在故障
2. DIMM070槽位故障

这个时候就可以使用"交叉验证"来判断故障原因

---

内存交叉验证

以上面的DIMM070故障为例，我们更换了故障槽位的内存，但是故障依旧

这时我们可以把更换过的内存重新插上，将故障槽位的内存与相邻槽位的内存对调，如果故障槽位不变说明是DIMM070槽位故障；如果故障位置跟随变化，则可以判定为内存条故障

有时候我们也称这种方法为"最小化测试"，交叉验证属于"最小化测试"之一

---

硬盘故障分析

AppDump\sensor_alarm下current_event.txt中

Event Num  | Event Time                     | Entity Name          | Sensor Name          | Alarm level  | Event Desc
1          | 2026-04-18 Saturday 03:04:09   | Disk                 | DISK8                | Minor        | The disk Disk8 state is abnormal.
2          | 2026-04-18 Saturday 03:04:01   | Disk                 | DISK8                | Major        | The disk Disk8 is missing.

Disk8 出现 Missing，说明 BMC 已经无法正常识别该槽位硬盘。

常见原因包括：

1. 硬盘本体故障
2. 硬盘掉线或接触不良
3. 硬盘背板/线缆/Expander 异常
4. RAID 卡或存储链路异常
5. NVMe 场景下可能涉及 PCIe 链路异常

这种情况可以优先按故障硬盘处理，但更换前应确认 RAID 状态、业务冗余状态和故障盘槽位，避免误拔正常盘

如果更换硬盘后故障依旧存在，则需要继续排查硬盘槽位、SAS 线缆、硬盘背板、Expander、RAID 卡或 NVMe PCIe 链路。可以先进行重新插拔和交叉验证，如果故障固定在同一槽位，再考虑背板、线缆或控制器方向。

这种情况下BMC已经识别到故障硬盘，所以服务器前面板对应的硬盘故障槽位会亮起红灯；还有一种情况是BMC识别不到故障硬盘，这种情况下需要在系统内查看故障硬盘，找到在BMC上的对应关系，在BMC点灯------即让故障硬盘槽位亮起红灯

---

电源故障分析

先看AppDump/event下的current_event.txt

看到目前没有告警

System in health state.

说明告警已经消除了，看下历史告警sel.txt

发现历史有多次PSU1的故障告警，且每次都是持续70秒左右

66      |2026-06-24 00:09:32 |Critical    |0x0300000E  |Deasserted  |The AC/DC input of PSU 1 is lost or out-of-range.
65      |2026-06-24 00:08:20 |Critical    |0x0300000D  |Asserted    |The AC/DC input of PSU 1 is lost or out-of-range.
64      |2026-06-23 00:41:16 |Critical    |0x0300000E  |Deasserted  |The AC/DC input of PSU 1 is lost or out-of-range.
63      |2026-06-23 00:40:03 |Critical    |0x0300000D  |Asserted    |The AC/DC input of PSU 1 is lost or out-of-range.

40      |2026-06-12 04:06:39 |Critical    |0x0300000E  |Deasserted  |The AC/DC input of PSU 1 is lost or out-of-range.
39      |2026-06-12 04:05:27 |Critical    |0x0300000D  |Asserted    |The AC/DC input of PSU 1 is lost or out-of-range.
38      |2026-06-12 00:46:58 |Critical    |0x0300000E  |Deasserted  |The AC/DC input of PSU 1 is lost or out-of-range.
37      |2026-06-12 00:45:44 |Critical    |0x0300000D  |Asserted    |The AC/DC input of PSU 1 is lost or out-of-range.

到AppDump\power_mgmt的psu_info.txt看下当前PSU电压

可以看到当前两块 PSU 均在位，输出电压 Vout 均为 12V，未见明显异常

Slot   |  presence  |  Manufacturer     |  Type                              |  SN                                |  Version                    |  Rated Power   |  InputMode  |  PartNum           |  DeviceName        |  Vin       |  Vout    
1      |  present   |  HUAWEI           |  PAC2000S12-B1                     |  xxxxxxxxxxxxxxxxxxxx              |  DC:111 PFC:111             |  2000          |  AC        |  xxxxxxxx          |  PSU1              |  225.00    |  12.00   
2      |  present   |  HUAWEI           |  PAC2000S12-B1                     |  xxxxxxxxxxxxxxxxxxxx              |  DC:111 PFC:(QB)111         |  2000          |  DC        |  xxxxxxxx          |  PSU2              |  270.00    |  12.00   

看下告警时间电源情况AppDump\power_strategy下的power_statistics.csv

没办法精准采集到这个时间段

这个时候就要结合外部情况来判断了

比如问下客户，告警临近时间有没有人员在施工，或者机柜在倒换测试什么的

相邻设备有没有类似告警，因为告警提示的是lost or out-of-range并非fault/fail，并且每次都是告警70秒后自动恢复

不排除也有误告警的可能性存在

如果允许可以联系电源厂商进行深度分析

如果条件允许，可以先交换 PSU1/PSU2 的电源线、PDU 口或电源模块位置，观察告警是否跟随电源线、PDU 口或 PSU 模块转移。

如果告警始终固定在 PSU1 槽位，则需要进一步考虑 PSU 槽位或电源背板问题。

如果是单台反复固定的某一个PSU槽位故障，可以考虑：

1. PSU1 电源线是否松动
2. PSU1 所接 PDU 口是否异常
3. PSU1 模块是否异常
4. PSU 槽位或电源背板是否异常

如果是多台服务器同时，且均在相邻位置

则应该考虑是机房机柜或者供电问题

---

CPU高温告警

一样，先看当前告警

先看AppDump/event下的current_event.txt

看到目前没有告警

System in health state.

然后再看sel日志，发现cpu2有一个瞬时高温告警

ID      |Generation Time     |Severity    |Event Code  |Status      |Event Description
66      |2026-06-20 22:29:04 |Major       |0x00000004  |Deasserted  |CPU 2(CpuBoard1 CPU2) temperature is too high and will be underclocked.
65      |2026-06-20 22:29:03 |Major       |0x00000003  |Asserted    |CPU 2(CpuBoard1 CPU2) temperature is too high and will be underclocked.

我们可以再去看下cpu的温度情况AppDump\sensor下的sensor_info.txt

目前的温度很正常，才40多，距离110的阈值差远了

sensor id  | sensor name      | value      | unit         | status | lnr        | lc         | lnc        | unc      | uc         | unr        | phys   | nhys  
0x42       | CPU1_Temp        | 44.000     | degrees C    | ok     | na         | na         | na         | 105.000  | 110.000    | na         | 2.000  | 2.000 
0x4b       | CPU2_Temp        | 42.000     | degrees C    | ok     | na         | na         | na         | 105.000  | 110.000    | na         | 2.000  | 2.000 

但是我们发现一个不太正常的数据

这个PCIE5网卡（实际上是DPU智能网卡），温度高达91，距离阈值差9度

如果某个时刻负荷加大，或者周围环境的温度变高（比如有人施工打开了机柜门），就有可能触发告警

0x73       | PCIe5 INIC CPU_Temp | 91.000     | degrees C    | ok     | na         | na         | na         | 100.000  | na         | na         | 2.000  | 2.000 

需要注意的是，SEL 中触发告警的是 CPU2 温度过高，而当前 sensor_info 中 CPU2_Temp 只有 42℃，说明采集日志时 CPU2 温度已经恢复正常，无法直接还原告警瞬间的温度。

同时，PCIe5 INIC CPU_Temp 当前为 91℃，接近 100℃阈值。这个传感器对应的是 PCIe5 上的智能网卡/DPU，而不是主板 CPU2 本体。

因此，不能直接判定 CPU2 高温一定由 DPU 导致。但由于该 DPU 位于 CPU2 一侧，并且业务主要运行在 DPU 上，DPU 高负载、高温、局部风道、风扇策略或机柜环境都有可能影响 CPU2 附近的局部热环境。

结合当前情况看，该告警只有 1 秒左右，且当前 CPU1/CPU2 温度正常，可以先按瞬时高温或局部热环境异常观察处理。建议后续关注 DPU 温度、风扇转速、机柜进风温度、业务负载以及是否再次出现 CPU2 underclocked 告警。

DPU 在高负载业务场景下温度偏高并不罕见，但 91℃ 已经接近 100℃阈值，仍建议持续关注。

---

总结

BMC 日志分析的核心不是只看某一条告警，而是要结合当前告警、历史告警、传感器状态、部件状态和系统内日志综合判断。

---

说明

免责声明与版权声明

本文内容由个人发布，仅用于学习、技术研究与经验交流。

文中涉及的软件（包括正版及第三方版本）仅供测试与学习用途，不构成任何形式的分发、破解、商业使用或侵权行为的鼓励。若您需要长期使用或商业部署，请前往官方网站购买或获取正版授权。

作者不对任何软件的使用、修改、传播及由此产生的后果承担法律责任。读者应自行判断、下载与使用软件，并遵守所在地法律法规及相关许可协议。

部分内容参考或摘录自公开资料、官方文档或其他技术文章，均已尽可能注明原作者及来源链接。若原作者或版权方认为本文存在不当引用或侵权内容，请联系作者处理，作者将在核实后及时修改或删除相关内容。

---

知识共享许可声明

除特别说明外，本文中的原创文字、图片、图表及资料均依据：

CC BY-NC-SA 4.0（署名－非商业性使用－相同方式共享）

许可协议发布。

您可以在遵守本协议的前提下：

• 复制、转载和分享本文内容；
• 对本文内容进行修改、改编和二次创作；
• 将本文内容用于个人学习、研究和非商业用途。

同时必须满足以下条件：

• 保留原作者署名及原文链接；
• 明确标注内容来源；
• 不得将本文及其衍生作品用于任何商业用途；
• 基于本文进行修改、改编或再创作的作品，必须继续采用相同协议进行发布。

---

特别声明

未经作者书面授权，禁止以下行为：

• 将本文原创内容用于商业培训、付费课程、付费社群、收费咨询等商业活动；
• 将本文原创内容转载至以盈利为目的的网站、平台、出版物或知识付费平台；
• 将本文原创内容批量采集、镜像、聚合或作为数据库内容进行商业运营；
• 将本文原创内容用于人工智能模型训练、知识库构建、数据集整理或其他商业化用途；
• 删除、修改或隐藏原作者署名、原文链接及版权声明。

对于违反上述声明的行为，作者保留依法追究相关责任的权利。

---

AI 辅助生成声明

本文部分内容在撰写、整理、润色或结构优化过程中使用了 AI 工具进行辅助生成。

AI 生成内容仅作为写作辅助参考，最终内容已由作者进行人工审阅、修改、校对与确认。本文观点、技术步骤、命令示例及相关说明均以作者最终发布版本为准。

读者在参考本文内容进行实际操作前，应结合自身环境进行验证，作者不因 AI 辅助生成内容可能存在的遗漏、错误或不适用情况承担额外责任。