老爷子身子骨真的好，特硬朗，还敬业，比大多数演员都强。有一句词要在进场前说，隔着十几米就听到了，中间调光换机位讲戏二三十分钟，别的腕都赶紧摸鱼坐着，我们也往旁边一靠休息，老爷子就往那一站一步不带挪的。进组就带了一个随从人员据说是家人，四字进来带了一群保镖，我和朋友就开始了找人群中到底哪些是保镖的小游戏。
一颗原本用于测量地球湿度的卫星SMAP，如今却意外成为了电子战场上的“幽灵追踪者”，清晰地捕捉到未经授权的无线电频率干扰信号。地图上一个个红点，很可能代表着干扰、欺骗或某种高功率电子战发射。
这些信号并非随机分布，而是与俄罗斯的电子战阵地、乌克兰的无人机走廊、前线集结区域以及后方一些值得关注的地点几乎完美重合。
那么，SMAP究竟是如何做到这一切的呢？通常情况下，SMAP以被动方式在1.41 GHz的L波段接收地球的黑体辐射，用于监测土壤湿度和海洋盐度。然而，当数百瓦的射频能量涌入这个频段时，SMAP便会敏锐地察觉。
这几乎是毫不费力地捕捉到的。在干净的区域，亮度温度约为270–310 K。沙漠地区可能会稍高，达到330 K。但当亮度温度飙升至360、370，甚至375 K时，那绝非太阳的自然辐射，而是干扰器的强烈信号。
为何要干扰L波段？原因在于，1.4 GHz频段不仅用于和平的地球观测，还与一些极具实战价值的军事信号相邻。
干扰或接近这个频段的信号可能会扰乱无人机的指挥与控制链路，特别是那些定制或改装的系统；FPV无人机的视频传输；全球导航卫星系统信号及其易被欺骗的谐波；卫星遥测和下行链路；以及无源雷达或传感系统。
在现代冲突中，干扰L波段意味着致盲无人机、降低目标精度并切断情报、监视与侦察能力。这绝非偶然，而是蓄意的行为。
那些规定“禁止在此频段发射信号”的国际条约，在生死攸关的无人机群攻面前显得苍白无力。
欢迎来到干扰区！尽管SMAP并非用于军事目的，但如果它会玩游戏，那么第聂伯罗、辛菲罗波尔和克里维里赫很可能已登上排行榜榜首。这三个地区在L波段发出了远超自然水平的亮度温度，高达370K以上，无疑进入了射频干扰的“高分区域”。无需过多解释，频谱本身已说明一切。
这一切信息都来源于公开渠道。无需动用无人机，无需入侵卫星信号，也无需贿赂任何操作人员。仅仅依靠一颗气候卫星、一些Python代码和一点时间，便绘制出了一张乌克兰、克里米亚和俄罗斯部分地区正在发生的实时电磁战地图。
本文译自 Radio&Nukes，由 BALI 编辑发布。
这些信号并非随机分布，而是与俄罗斯的电子战阵地、乌克兰的无人机走廊、前线集结区域以及后方一些值得关注的地点几乎完美重合。
那么，SMAP究竟是如何做到这一切的呢？通常情况下，SMAP以被动方式在1.41 GHz的L波段接收地球的黑体辐射，用于监测土壤湿度和海洋盐度。然而，当数百瓦的射频能量涌入这个频段时，SMAP便会敏锐地察觉。
这几乎是毫不费力地捕捉到的。在干净的区域，亮度温度约为270–310 K。沙漠地区可能会稍高，达到330 K。但当亮度温度飙升至360、370，甚至375 K时，那绝非太阳的自然辐射，而是干扰器的强烈信号。
为何要干扰L波段？原因在于，1.4 GHz频段不仅用于和平的地球观测，还与一些极具实战价值的军事信号相邻。
干扰或接近这个频段的信号可能会扰乱无人机的指挥与控制链路，特别是那些定制或改装的系统；FPV无人机的视频传输；全球导航卫星系统信号及其易被欺骗的谐波；卫星遥测和下行链路；以及无源雷达或传感系统。
在现代冲突中，干扰L波段意味着致盲无人机、降低目标精度并切断情报、监视与侦察能力。这绝非偶然，而是蓄意的行为。
那些规定“禁止在此频段发射信号”的国际条约，在生死攸关的无人机群攻面前显得苍白无力。
欢迎来到干扰区！尽管SMAP并非用于军事目的，但如果它会玩游戏，那么第聂伯罗、辛菲罗波尔和克里维里赫很可能已登上排行榜榜首。这三个地区在L波段发出了远超自然水平的亮度温度，高达370K以上，无疑进入了射频干扰的“高分区域”。无需过多解释，频谱本身已说明一切。
这一切信息都来源于公开渠道。无需动用无人机，无需入侵卫星信号，也无需贿赂任何操作人员。仅仅依靠一颗气候卫星、一些Python代码和一点时间，便绘制出了一张乌克兰、克里米亚和俄罗斯部分地区正在发生的实时电磁战地图。
本文译自 Radio&Nukes，由 BALI 编辑发布。
QEMU 10.0 释出
2025-04-23 18:34 by 先知
跨架构全系统模拟器 QEMU 释出了 v10.0.版本。新特性包括：龙芯 QEMU 支持 CPU 热插拔、半虚拟化 IPI、steam time 等；RISC-V QEMU 支持新 ISA/扩展，支持 Tenstorrent Ascalon CPU、香山南湖 CPU 以及 Microblaze-V 通用板；支持 Intel Clearwater Forest CPU 和 Sierra Forest v2 CPU 型号；VirtIO SCSI 设备支持多队列；QEMU VFIO 支持旧款的 ATI X550 GPU，等等。QEMU 项目由 Fabrice Bellard 创建，最初设想在非 x86 平台上运行 x86 Linux 二进制程序，随后转变成跨架构的全系统模拟器。
wiki.qemu.org/ChangeLog/10.0
#开源
2025-04-23 18:34 by 先知
跨架构全系统模拟器 QEMU 释出了 v10.0.版本。新特性包括：龙芯 QEMU 支持 CPU 热插拔、半虚拟化 IPI、steam time 等；RISC-V QEMU 支持新 ISA/扩展，支持 Tenstorrent Ascalon CPU、香山南湖 CPU 以及 Microblaze-V 通用板；支持 Intel Clearwater Forest CPU 和 Sierra Forest v2 CPU 型号；VirtIO SCSI 设备支持多队列；QEMU VFIO 支持旧款的 ATI X550 GPU，等等。QEMU 项目由 Fabrice Bellard 创建，最初设想在非 x86 平台上运行 x86 Linux 二进制程序，随后转变成跨架构的全系统模拟器。
wiki.qemu.org/ChangeLog/10.0
#开源
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 额度！
