openUBMC2512出现hwproxy组件挂死情况

lihang111 · 2026 年4 月 27 日 09:07

问题描述

在进行一些snmp的测试后，突然发现机器无法通过BMC上电，发现hwproxy组件挂死，发hwproxy相关命令都会超时。

framework.log:

一键收集日志如下：
null_20260427-1445.tar.gz (8.3 MB)

ubmc_assistant · 2026 年4 月 27 日 09:14

答案内容由AI生成，仅供参考：

结论与建议

项目	内容
问题定性	`bmc.kepler.hwproxy` 服务因硬件访问阻塞导致挂死，引发 D-Bus 超时，进而影响 BMC 上电与管理功能
最可能原因	1. SR 配置错误导致访问异常设备 2. 某硬件设备（如 SMC、RAID）响应异常 3. SNMP 高频查询压垮服务
建议行动	1. 检查 SR 配置准确性 2. 分析 `hw_stream.log` 和 `hwproxy.log` 3. 启用 debug 日志定位卡死点 4. 评估是否需升级 `hwproxy` 组件版本

注意：请勿频繁手动重启，以免掩盖真实故障根源。建议在测试环境复现并抓取完整日志用于分析。

如有必要，请提供 hwproxy.log 及 hw_stream.log 的完整内容以进一步深入分析。

点击此处查看详细分析解答

openUBMC 25.12 环境下 hwproxy 组件挂死问题分析与排查

根据用户描述，在 openUBMC 25.12 版本系统中，执行 SNMP 测试后出现 hwproxy 组件挂死的问题，导致 BMC 无法上电、对硬件操作超时，相关 D-Bus 调用失败。以下基于提供的日志、知识图谱（KG）和文档内容进行综合分析和排查建议。

问题现象总结

核心故障：bmc.kepler.hwproxy 服务无响应，所有相关命令超时。

典型错误命令：

buse tl --user call bmc.kepler.hwproxy ...  # 错误拼写应为 busctl
→ Call failed: Connection timed out

日志关键线索：
- 多次出现 failed to get stat of skynet service snlua hproxyx/service/main: TIMEOUT
- Healthcheck failed, error: org.freedesktop.DBus.Error.NoReply
- component[hproxyx] is in an abnormal status 3 times, and it will attempt to restart for recovery
- 提示 hproxyx 健康检查失败并尝试重启恢复

根因分析（基于 Context 信息）

1. `bmc.kepler.hwproxy` 功能定位

根据知识图谱数据：

bmc.kepler.hwproxy 是一个 D-Bus 服务，作为 BMC 系统中的硬件代理核心组件，负责：

管理硬件访问（如 Scanner, EEPROM, PSU, CPLD 等）
抽象 I2C、HisPort 等总线通信
暴露设备资源树供其他服务调用（如 mdbctl lsprop, busctl 等）
作为 general_hardware、storage 等组件的底层依赖

因此，一旦 hwproxy 挂死，整个系统的硬件访问链路将中断，导致无法读取传感器、控制电源、升级固件等问题。

2. 超时错误类型分析

日志中反复出现：

org.freedesktop.DBus.Error.NoReply: Did not receive a reply...

此为典型的 D-Bus Reply Timeout 错误，表示调用方等待响应超时。

结合 KG 中定义：

DBUS Reply Timeout：消息总线未能在预期时间内收到回复，造成通信失败。

进一步说明 hproxyx（即 hwproxy 服务）进程已陷入阻塞、死循环或完全卡死状态，无法响应 D-Bus 请求。

3. 日志中的程序堆栈异常

framework.log 中存在多次重复堆栈：

stack traceback: 
  /opt/bmc/libmc/lualib/mc/mdbo/object_manage.lua:500: in function 'wait for children removed'
  ...
  [repeated 5 times in 330s]

表明系统中某些 Lua 服务（特别是依赖 hwproxy 的子对象）在尝试关闭或重启时长时间等待子组件销毁未果，形成等待链死锁或无限循环。

这通常由以下原因导致：

hwproxy 内部某个硬件访问线程被阻塞（如 I2C 总线卡死）
对某设备（如 SMC、RAID 控制器）发起请求后未收到应答，且无超时处理机制
子服务退出流程设计缺陷，依赖 hwproxy 回应但其已无响应

4. 服务名称差异：“hproxyx” vs “hwproxy”

日志中服务名为 snlua hproxyx/service/main，而非 hwproxy，说明：

hproxyx 是 hwproxy 的内部运行实例名称（可能为 Skynet 框架下的模块别名）
maca 组件负责监控其健康状态（见 maca ERROR: [hproxyx]Healthcheck failed）

KG 支持：maca 是一个系统监控框架，用于检测关键组件状态并尝试自动重启。

当健康检查连续失败 3 次后，maca 尝试重启服务（framework.service restart finished），但未能恢复功能，说明 hwproxy 重启后仍无法正常初始化。

5. 外部触发因素：SNMP 测试

用户提到问题出现在 SNMP 测试之后。SNMP 查询可能涉及：

获取温度、电源状态等传感器数据
这些数据路径依赖 hwproxy 访问底层硬件（如 LM75、SMC）

若 SNMP 批量轮询频率过高或存在 bug，可能导致：

hwproxy 瞬间接收大量请求
某些请求因硬件响应慢而阻塞，引发线程池耗尽
最终服务整体卡死

推荐排查步骤

1. 确认当前 `hwproxy` 服务状态

# 查看 D-Bus 上服务是否存在
busctl --user list-names | grep bmc.kepler.hwproxy

# 检查服务是否存活
busctl --user tree bmc.kepler.hwproxy

若返回 Connection timed out，说明服务进程存在但无响应；若返回 ServiceUnknown，则服务未启动。

2. 检查相关日志文件

重点查看以下几个日志：

日志文件	说明
`/var/log/hwproxy.log`	`hwproxy` 自身的日志输出，包含硬件访问详情
`/var/log/skynet.log`	Skynet 框架运行日志，查看 `hproxyx` 启动是否成功
`/var/log/maca.log`	监控组件日志，确认是否执行了重启动作
`/var/log/hw_stream.log`	硬件流日志（参考 Search Result #8），可能记录访问超时细节

搜索关键词：

timeout
write failed
bus locked
chip plugin_request

3. 检查 SR 配置是否正确（关键！）

参考 Search Result #2《V3硬件访问错误排查指南》：

hwproxy 的行为高度依赖 SR 文件中描述的硬件拓扑结构。若 SR 中地址、总线类型、设备属性配置错误，可能导致访问非法地址或设备未响应，从而引起超时甚至挂死。

排查项：

PSU、SMC、RAID 卡等新增设备的 SR 定义是否准确？
I2C 地址、HisPort 端口号、读写长度等参数是否正确？
是否存在设备地址冲突或总线抢占？

可使用如下命令验证配置：

# 获取硬件拓扑信息
mdbctl lsobj /bmc/kepler/hwproxy

4. 检查是否有硬件设备异常

硬件层问题也可能导致 hwproxy 卡死：

SMC（扩展板 MCU）固件异常或死机
I2C 总线被某个设备长时间拉低
CPLD 或 EEPROM 响应缓慢或无响应

可通过以下方式验证：

检查电源模块（PSU）、背板（ExpBoard）物理连接是否稳定
使用示波器检测 I2C CLK/SDA 是否正常
临时移除部分非关键设备（如 RAID 卡）测试是否复现

参考 Search Result #8：RAID 卡通信失败曾导致 hwproxy 超时刷屏日志。

5. 检查并升级组件版本兼容性

当前环境为 openUBMC 25.12 LTS SP1，需确认：

bmc.kepler.hwproxy 版本是否为最新稳定版？
是否存在已知 bug？（例如社区 2506 版本存在对象偶现丢失问题）

建议核对组件版本一致性：

conan info . -r openubmc/stable | grep hwproxy

若有更新版本，建议升级至修复版本。

6. 启用 debug 日志获取更详细信息

参考 Search Result #2：

# 开启 hwproxy debug 日志
busctl --user set-property bmc.kepler.hwproxy /bmc/kepler/hwproxy/MicroComponent bmc.kepler.MicroComponent.DebugLevel s debug

然后复现问题，观察日志输出细节，定位具体在哪一步骤卡住。

临时规避措施

重启 BMC：
```
reboot
```
若问题偶发，重启可暂时恢复。
禁用 SNMP 高频轮询：
调整 SNMP 监控间隔，避免短时间内发起大量硬件查询请求。
添加访问超时机制：
确保 hwproxy 内部对每个硬件访问设置合理超时时间（如 1s），避免永久阻塞。

参考资料支持

[Search Result #2]：《V3硬件访问错误排查指南》——详细说明如何通过日志和配置排查 hwproxy 错误
[Search Result #8]：类似问题（RAID卡通信失败导致 hwproxy 超时）的历史案例
KG 实体：bmc.kepler.hwproxy, DBUS Reply Timeout, maca, general_hardware

结论与建议

项目	内容
问题定性	`bmc.kepler.hwproxy` 服务因硬件访问阻塞导致挂死，引发 D-Bus 超时，进而影响 BMC 上电与管理功能
最可能原因	1. SR 配置错误导致访问异常设备 2. 某硬件设备（如 SMC、RAID）响应异常 3. SNMP 高频查询压垮服务
建议行动	1. 检查 SR 配置准确性 2. 分析 `hw_stream.log` 和 `hwproxy.log` 3. 启用 debug 日志定位卡死点 4. 评估是否需升级 `hwproxy` 组件版本

注意：请勿频繁手动重启，以免掩盖真实故障根源。建议在测试环境复现并抓取完整日志用于分析。

如有必要，请提供 hwproxy.log 及 hw_stream.log 的完整内容以进一步深入分析。

huangzhiyu · 2026 年4 月 28 日 01:33

这个是个已知问题，最新版本应该带上了修复

lihang111 · 2026 年4 月 28 日 01:40

你好，请问是2603版本修复了吗，具体是hwproxy哪个版本修复了该问题，我们想在2512 LTS上替换。

huangzhiyu · 2026 年4 月 28 日 02:13

libmc4lua 1.110.6

huangzhiyu · 2026 年4 月 28 日 02:14

其他组件不配套，构建可能会报错

lihang111 · 2026 年4 月 28 日 02:17

好的，谢谢。

huangzhiyu · 2026 年4 月 28 日 08:02

嗯，有问题再回复

luohao211737 · 2026 年4 月 28 日 08:12

@huangzhiyu 我这个问题 NVMe盘快速热插拔导致storage组件挂死 - Hardware SIG - openUBMC 论坛类似，也是需要更新libmc4lua 1.110.6解决吗，这个更新是在LTS SP1吗

huangzhiyu · 2026 年4 月 28 日 08:15

2026-04-27 14:12:20.890471 [:00000010] framework: stack traceback: ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:500: in function ‘wait_for_children_removed’ ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:568: in function ‘’ /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0> [builtin#21]: at 0xffff80e35d28 [C]: in function ‘pcall’ ./opt/bmc/libmc/lualib/mc/context.lua:212: in function ‘with_context’ ./opt/bmc/libmc/lualib/mc/app_preloader.lua:97: in function ‘’ /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0>

有类似这种报错吗，可以在framework.log搜下wait_for_children_removed

luohao211737 · 2026 年4 月 28 日 08:21

也有这个报错

2026-04-28 06:44:20.569093 [:00000010] hardware: stack traceback:  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:500: in function 'wait_for_children_removed'  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:568: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0>  [builtin#21]: at 0xffffb1d3ad28  [C]: in function 'pcall'  ./opt/bmc/libmc/lualib/mc/context.lua:212: in function 'with_context'  ./opt/bmc/libmc/lualib/mc/app_preloader.lua:97: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0> [repeated 5 times in 360s from 2026-04-28 06:38:20.275557 to 2026-04-28 06:44:20.569093]
2026-04-28 06:49:20.741925 [:00000010] hardware: stack traceback:  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:502: in function 'wait_for_children_removed'  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:568: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0>  [builtin#21]: at 0xffffb1d3ad28  [C]: in function 'pcall'  ./opt/bmc/libmc/lualib/mc/context.lua:212: in function 'with_context'  ./opt/bmc/libmc/lualib/mc/app_preloader.lua:97: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0> [repeated 6 times in 390s from 2026-04-28 06:42:50.529745 to 2026-04-28 06:49:20.741925]
2026-04-28 06:49:40.986372 [:00000010] hardware: stack traceback:  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:500: in function 'wait_for_children_removed'  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:568: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0>  [builtin#21]: at 0xffffb1d3ad28  [C]: in function 'pcall'  ./opt/bmc/libmc/lualib/mc/context.lua:212: in function 'with_context'  ./opt/bmc/libmc/lualib/mc/app_preloader.lua:97: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0> [repeated 6 times in 270s from 2026-04-28 06:44:20.569093 to 2026-04-28 06:48:50.724037][flush]
2026-04-28 06:49:50.760071 [:00000010] hardware: stack traceback:  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:500: in function 'wait_for_children_removed'  ./opt/bmc/libmc/lualib/mc/mdb/object_manage.lua:568: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0>  [builtin#21]: at 0xffffb1d3ad28  [C]: in function 'pcall'  ./opt/bmc/libmc/lualib/mc/context.lua:212: in function 'with_context'  ./opt/bmc/libmc/lualib/mc/app_preloader.lua:97: in function ''  /opt/bmc/skynet/lualib/skynet.lua: in function </opt/bmc/skynet/lualib/skynet.lua:0>

huangzhiyu · 2026 年4 月 28 日 08:27

那应该是一类问题

话题		回复	浏览量
hwproxy组件状态异常， Hardware SIG 提问求助	1	81	2025 年8 月 22 日
hw_proxy社区最新代码，有没有什么版本依赖交流互助区提问求助	4	62	2026 年9 月 17 日
升级到openUBMC后，CPU侧无法检测到对应的BMC的存在交流互助区提问求助	25	416	2026 年3 月 23 日
无签名UBMC上无法继续更新BMC固件交流互助区提问求助	17	419	2026 年2 月 25 日
hwproxy组件报错如何进一步定位交流互助区提问求助	6	200	2025 年11 月 13 日

openUBMC2512出现hwproxy组件挂死情况

问题描述

结论与建议

openUBMC 25.12 环境下 hwproxy 组件挂死问题分析与排查

问题现象总结

根因分析（基于 Context 信息）

1. bmc.kepler.hwproxy 功能定位

2. 超时错误类型分析

3. 日志中的程序堆栈异常

4. 服务名称差异：“hproxyx” vs “hwproxy”

5. 外部触发因素：SNMP 测试

推荐排查步骤

1. 确认当前 hwproxy 服务状态

2. 检查相关日志文件

3. 检查 SR 配置是否正确（关键！）

4. 检查是否有硬件设备异常

5. 检查并升级组件版本兼容性

6. 启用 debug 日志获取更详细信息

临时规避措施

参考资料支持

结论与建议

相关话题

1. `bmc.kepler.hwproxy` 功能定位

1. 确认当前 `hwproxy` 服务状态