如下内容由我回顾处理过程，chatgpt整理。
以下是你提供信息的整理版，便于归档或技术记录：
---
IBM x3950 X5 堆叠服务器内存识别故障排查与恢复全流程记录
一、系统基础结构
服务器型号：IBM x3950 X5（双节点堆叠）
系统版本：RHEL 5.5
CPU 配置：
每节点配有 4 颗物理 CPU，共计 8 颗 CPU（编号 CPU0–CPU7）
内存配置：
每节点 8 个内存板，每板插有 2 条 4GB DIMM
共计 16 个内存板、32 条 4GB 内存，总内存为 128GB
NUMA 架构：
每个 NUMA Node 对应 1 颗 CPU 和其下 2 个内存板
共划分为 8 个 NUMA Node（node0–node7）
---
二、初始问题现象
初次更换从节点（服务器 2）内存板 8 上的两条内存后：
堆叠启动失败，主机卡在 00 bb 状态
主节点电源按钮慢闪，从节点快闪直至熄灭
从节点 IMM 接口无响应或 hang 死
排查过程中发现：
从节点 QPI 接口针脚处有一块发泡海绵，疑似引发接触不良
拆除海绵后，主机可恢复正常堆叠启动状态
---
三、系统层面内存检测情况
dmidecode -t 17 和 grep Samsung 确认 32 条内存均 Present，状态正常
IMM 管理界面亦显示全部内存条均在线、无报错
系统启动后：
numactl -H 显示：仅识别 node0, node2-4, node6-7，缺少 node1 和 node5
free -g 和 dmesg 显示可用物理内存为 98GB
说明有约 30GB 内存未被识别（缺少两个 node，每 node 理应配 16GB）
---
四、第一阶段排查与恢复：node5
对从节点逐块测试内存板定位灯，发现 内存板 4 故障灯亮
更换该板两条内存后，重启系统：
node5 成功上线
系统识别内存增至 110GB
---
五、第二阶段分析：定位 node1
基于 NUMA 拓扑结构分析：
每个 NUMA node ≈ 1 个 CPU + 2 块内存板
node5 → CPU5 → 从节点内存板 3、4
node1 → CPU1 → 推测应为主节点内存板 3、4
进一步验证命令：
dmesg | grep -i node
grep . /sys/devices/system/cpu/cpu*/topology/physical_package_id
cat /sys/devices/system/node/node*/cpulist
分析得出：
CPU0–CPU1 的核心（core0–core19）都归属 node1
剩余 CPU 对应核心被平均分配至其他 node（每 node 10 个核心）
确认 node1 绑定 CPU1，对应主节点内存板 3、4
---
六、最终处理
更换主节点内存板 3、4 上的两条 4GB DIMM 后重启系统
验证：
numactl -H 显示所有 node0–node7 均已上线
总内存恢复至完整的 128GB
---
七、NUMA Node–CPU–内存板 映射表
---
八、经验总结
堆叠服务器启动失败，除内存条本身故障外，需注意：
QPI 接口、Bridge 间连接质量
发泡海绵等异物可能引发严重启动异常
IMM 报错不完全可信，需结合定位灯和系统实际 NUMA 状态多维度分析
RHEL 5.5 下无法识别部分内存时，应重点检查是否存在：
NUMA node 缺失（node 未上线）
DIMM 本身未识别或未分配到对应 SRAT 映射区域。
以下是你提供信息的整理版，便于归档或技术记录：
---
IBM x3950 X5 堆叠服务器内存识别故障排查与恢复全流程记录
一、系统基础结构
服务器型号：IBM x3950 X5（双节点堆叠）
系统版本：RHEL 5.5
CPU 配置：
每节点配有 4 颗物理 CPU，共计 8 颗 CPU（编号 CPU0–CPU7）
内存配置：
每节点 8 个内存板，每板插有 2 条 4GB DIMM
共计 16 个内存板、32 条 4GB 内存，总内存为 128GB
NUMA 架构：
每个 NUMA Node 对应 1 颗 CPU 和其下 2 个内存板
共划分为 8 个 NUMA Node（node0–node7）
---
二、初始问题现象
初次更换从节点（服务器 2）内存板 8 上的两条内存后：
堆叠启动失败，主机卡在 00 bb 状态
主节点电源按钮慢闪，从节点快闪直至熄灭
从节点 IMM 接口无响应或 hang 死
排查过程中发现：
从节点 QPI 接口针脚处有一块发泡海绵，疑似引发接触不良
拆除海绵后，主机可恢复正常堆叠启动状态
---
三、系统层面内存检测情况
dmidecode -t 17 和 grep Samsung 确认 32 条内存均 Present，状态正常
IMM 管理界面亦显示全部内存条均在线、无报错
系统启动后：
numactl -H 显示：仅识别 node0, node2-4, node6-7，缺少 node1 和 node5
free -g 和 dmesg 显示可用物理内存为 98GB
说明有约 30GB 内存未被识别（缺少两个 node，每 node 理应配 16GB）
---
四、第一阶段排查与恢复：node5
对从节点逐块测试内存板定位灯，发现 内存板 4 故障灯亮
更换该板两条内存后，重启系统：
node5 成功上线
系统识别内存增至 110GB
---
五、第二阶段分析：定位 node1
基于 NUMA 拓扑结构分析：
每个 NUMA node ≈ 1 个 CPU + 2 块内存板
node5 → CPU5 → 从节点内存板 3、4
node1 → CPU1 → 推测应为主节点内存板 3、4
进一步验证命令：
dmesg | grep -i node
grep . /sys/devices/system/cpu/cpu*/topology/physical_package_id
cat /sys/devices/system/node/node*/cpulist
分析得出：
CPU0–CPU1 的核心（core0–core19）都归属 node1
剩余 CPU 对应核心被平均分配至其他 node（每 node 10 个核心）
确认 node1 绑定 CPU1，对应主节点内存板 3、4
---
六、最终处理
更换主节点内存板 3、4 上的两条 4GB DIMM 后重启系统
验证：
numactl -H 显示所有 node0–node7 均已上线
总内存恢复至完整的 128GB
---
七、NUMA Node–CPU–内存板 映射表
---
八、经验总结
堆叠服务器启动失败，除内存条本身故障外，需注意：
QPI 接口、Bridge 间连接质量
发泡海绵等异物可能引发严重启动异常
IMM 报错不完全可信，需结合定位灯和系统实际 NUMA 状态多维度分析
RHEL 5.5 下无法识别部分内存时，应重点检查是否存在：
NUMA node 缺失（node 未上线）
DIMM 本身未识别或未分配到对应 SRAT 映射区域。
