IBM X3950堆叠服务器，RHEL5.5，双节点，每节点配4CPU、8内存板，16*4G内存，双节点物理内存共128G。系统中查看可寻址内存仅有110G。 初次拆机更换从节点内存板8的两根内存后，主机堆叠持续无法启动，经反复测试，调配启动顺序和时间，均出现从节点 IMM hang，以及主从节点卡00 bb，主节点电源按钮慢闪，从节点快闪直至熄灭情况。经排查，发现从节点QPI接口针脚处有一发泡海绵，疑似其导致接触不良，移除后，主机可正常恢复堆叠状态。
进入系统后，使用dmidecode -t 17和dmidecode -t 17 | grep Samsung | wc -l 查看物理内存数量为32条，状态均正常。IMM接口查看双节点内存均正常。numactl -H查看node0-7中，少1和5两个node。可用内存大小为98G，由于IMM无任何报错，对从节点进行拆机，依次点亮内存板故障定位灯，发现从节点4号内存板亮故障灯，更换其上两根4G内存，进入系统后，恢复至110G，node5上线。 由于系统中仍无任何报错，且其余内存板故障定位灯均显示绿色无故障，所以需要排查定位缺失的剩余16G内存故障来源。16G是来自于故障内存板的两根4G内存及同通道内存板的内存，故为16G。 经过对更换从节点4号内存板内存之后，node5上线的分析，以如下命令 dmesg | grep -i node grep . /sys/devices/system/cpu/cpu*/topology/physical_package_id 从命令输出中可以看到，核心0-9与核心10-19这20个核心均划归node1，而剩余核心20-21至70-79则分属剩余6个node，每node10个核心。
通过命令输出判定NODE-逻辑CPU-物理CPU关系，并判断物理CPU所使用的内存槽位。
按照映射关系，确定node1-CPU1所属内存为主节点的3、4内存板，对其进行更换处理，128G内存成功识别，node0-7均上线。
进入系统后，使用dmidecode -t 17和dmidecode -t 17 | grep Samsung | wc -l 查看物理内存数量为32条，状态均正常。IMM接口查看双节点内存均正常。numactl -H查看node0-7中，少1和5两个node。可用内存大小为98G，由于IMM无任何报错，对从节点进行拆机，依次点亮内存板故障定位灯，发现从节点4号内存板亮故障灯，更换其上两根4G内存，进入系统后，恢复至110G，node5上线。 由于系统中仍无任何报错，且其余内存板故障定位灯均显示绿色无故障，所以需要排查定位缺失的剩余16G内存故障来源。16G是来自于故障内存板的两根4G内存及同通道内存板的内存，故为16G。 经过对更换从节点4号内存板内存之后，node5上线的分析，以如下命令 dmesg | grep -i node grep . /sys/devices/system/cpu/cpu*/topology/physical_package_id 从命令输出中可以看到，核心0-9与核心10-19这20个核心均划归node1，而剩余核心20-21至70-79则分属剩余6个node，每node10个核心。
通过命令输出判定NODE-逻辑CPU-物理CPU关系，并判断物理CPU所使用的内存槽位。
按照映射关系，确定node1-CPU1所属内存为主节点的3、4内存板，对其进行更换处理，128G内存成功识别，node0-7均上线。
如下内容由我回顾处理过程，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 映射区域。
最近马斯克开放了 Grok3 的 API，充值 5 美元即可终身获得每月 150 美元的 Grok API 额度，只需要同意加入 xAI 的数据共享计划。已经薅到。
我主要通过虚拟信用卡 WildCard 充值，两年会员 +5 刀直充，基本总计 20 刀的价格即可。主要流程即是在 xAI 开发者平台的 Payment 页面完成账单地址和支付方式填写。最后充值上虚拟卡的 5 美元并 Share Data 就可以拉出 API 了。
现在 Grok3 和 Gemini 释放的 API 完全可以支持日常使用，Grok3 mini 速度也极其优异，平常 MCP 处理完全够用。
再次赞美丰盛的时代。
相关链接：
1 xAI 控制台
2 手把手教你薅马斯克 xAI 的 Grok 3 大羊毛：充 $5 终身每月获得 150 美元 API 额度！
啊诸君: https://jandan.net/t/5887342
今天的面试，技术岗，上来给我整了星座这一出，翻了翻下面和第二页的愚蠢问题，打了个问号跟对方说我们不合适就走了。
OO: 404 XX: 10
MG630: @让酒 真信星座能看性格的，这辈子有了👍
OO: 238, XX: 2
蛋友16ff27801c89a: 有的迷信老板还会问属相，说是有的属相不合财。
OO: 97, XX: 2
煎了个蛋: @让酒 用星座来推测性格，还不是迷信？
OO: 75, XX: 1
康师博: @让酒 星座看性格是真6，那你反推一下我这性格是什么星座？
OO: 63, XX: 1
SquareFong: @让酒 星座、属相、MBTI，这些东西你放在技术岗的一面？没有本质区别，伺候不了，扭头就走
OO: 56, XX: 2
日枝田史绪: 还不如问性取向
OO: 44, XX: 0
蛋友170060bc4e692: 有身份证还不知道星座属相吗？脑残公司
OO: 25, XX: 0
今天的面试，技术岗，上来给我整了星座这一出，翻了翻下面和第二页的愚蠢问题，打了个问号跟对方说我们不合适就走了。
OO: 404 XX: 10
MG630: @让酒 真信星座能看性格的，这辈子有了👍
OO: 238, XX: 2
蛋友16ff27801c89a: 有的迷信老板还会问属相，说是有的属相不合财。
OO: 97, XX: 2
煎了个蛋: @让酒 用星座来推测性格，还不是迷信？
OO: 75, XX: 1
康师博: @让酒 星座看性格是真6，那你反推一下我这性格是什么星座？
OO: 63, XX: 1
SquareFong: @让酒 星座、属相、MBTI，这些东西你放在技术岗的一面？没有本质区别，伺候不了，扭头就走
OO: 56, XX: 2
日枝田史绪: 还不如问性取向
OO: 44, XX: 0
蛋友170060bc4e692: 有身份证还不知道星座属相吗？脑残公司
OO: 25, XX: 0
昨天梦到趁看管不在翻窗闯入一个不允许进入的古迹，内部昏暗，没有光线，在上楼梯时被回来的看管发现，遂报警。
在警察出现在不远处的时候我掏出了手机，负责看管的老太太跟警察说他掏手机了可能要删东西一定要全检查一遍。我破罐子破摔想着不能被看到tg，点开termux运行23年在上海写好的自毁脚本。
在警察出现在不远处的时候我掏出了手机，负责看管的老太太跟警察说他掏手机了可能要删东西一定要全检查一遍。我破罐子破摔想着不能被看到tg，点开termux运行23年在上海写好的自毁脚本。
我大约3-4年前发现了这件事，我对自己的记忆进行实验性的修改/引导/刻意遗忘与捏造，效果好到一度怀疑现实，这件事情让我感到隐隐约约的恐惧。在意识到并发现且证实记忆可自行和他人引导捏造之后，我将结论告诉了朋友，并迅速结束了实验。因为它会动摇一个人对自我的信任，能够轻易的摧毁现实。
https://jandan.net/p/119878#/ “那这些“恢复”的记忆从哪来？研究者发现，记忆很容易被扭曲。你可能会不自觉地混入期待、假设或他人的说法，拼凑出一个并非原貌的版本。更惊人的是，用类似治疗师的引导性技术，研究者能让近三分之一的参与者“回忆”起从未发生的童年创伤——比如被噎住、住院或被动物袭击。这些虚假记忆细节丰富，仿佛真事。可这是在实验室故意植入的，现实中，一个同情客户的治疗师未必有意为之，却可能无意间制造幻觉。”
终于把手机掉音频驱动的问题解决了，先是老一套setprop结果无限重启。查日志查到SELinux 拦截了 audio 服务访问 /vendor/dsp（ADSP 固件目录）的权限，导致音频 DSP 无法加载 → HAL 初始化失败 → audioserver 崩溃重启 → 触发Watchdog，系统进入无限重启或完全无声音状态。
用setenforce 0命令尝试放过访问，失败，它只能修改“当前运行时”的 SELinux 模式，无法影响系统 early-init 阶段的权限策略执行。
最终解决方案是使用 Magisk SELinux Permissive 模块，让系统在引导阶段即处于 Permissive 模式，能够正常拉起audio服务，虽然降低了安全性，但起码解决了使用的问题。
用setenforce 0命令尝试放过访问，失败，它只能修改“当前运行时”的 SELinux 模式，无法影响系统 early-init 阶段的权限策略执行。
最终解决方案是使用 Magisk SELinux Permissive 模块，让系统在引导阶段即处于 Permissive 模式，能够正常拉起audio服务，虽然降低了安全性，但起码解决了使用的问题。
