风扇转速传感器对象添加异常问题

iss_wangzy · 2026 年2 月 6 日 03:49

问题描述

偶发性风扇转速传感器丢失，如下图：

目前尝试复现时发现，这个问题可能会发生在升级BMC、升级扩展板CPLD、插拔风扇等操作后。出现这个问题后重启BMC可恢复。风扇实际是正常运转的，并且不影响调速。

收集日志发现该问题由position在注册到资源树时超时引发。由于未能及时获取拓扑数据（topology data not exist），系统在二次尝试加载 Chip 资源过程中，底层脚本 chip.lua 抛出 “table index is nil” 错误，导致对象添加流程中断，并触发 DeleteObject 操作。
第一次尝试，报错为topology data not exist

这个是重试流程，报错和第一次不一样chip.lua 抛出 “table index is nil”

环境信息

软件版本：社区2509的代码

期望结果

请问这个问题是什么原因导致的呢？如何解决？

ubmc_assistant · 2026 年2 月 6 日 04:07

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

总结

项目	内容
问题本质	风扇传感器对象因拓扑数据未就绪导致注册失败，重试时因未处理空指针访问引发崩溃，最终对象被删除。
根本原因	BMC启动或设备热插拔时序与拓扑服务不匹配，缺乏健壮的错误恢复机制。
触发条件	升级、热插拔、CPLD变更等导致设备重枚举的操作。
临时解决	重启BMC可恢复。
长期建议	修复加载逻辑，增加拓扑等待、重试机制和空值保护，提升系统健壮性。

建议向开发团队提交此问题，并推动在后续版本中修复 hwpuroxy 组件中的 chip.lua 和 object_manage.lua 的异常处理逻辑。

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

风扇转速传感器对象添加异常问题分析

问题概述

用户反馈偶发性出现风扇转速传感器丢失的问题，具体表现为通过 ipmitool sensor 查看时，部分风扇（如 FAN2）的转速显示为 --，状态为 -- 或 nc，而实际风扇是正常运转且不影响系统调速。

该问题在 BMC升级、扩展板CPLD升级或插拔风扇后 偶发出现，重启BMC后可恢复。日志表明，问题核心在于 风扇传感器对象在注册到资源树时超时失败，并因底层脚本错误导致对象被删除。

根本原因分析

1. 注册流程失败链条

根据提供的日志分析，完整的异常发生链条如下：

第一阶段：初次注册失败

BMC系统尝试为风扇（如 FAN2，position: 01010303）加载硬件描述（CSR数据）并构建资源树。
在调用 AddObject 注册对象时尝试获取拓扑数据（topology data），但获取失败。
日志中出现关键错误：
```
position: 01010303 get topology failed
AddObjectComplete failed ... error: topology data not exist
```
这说明系统在初始化过程中，尚未完成拓扑构建，导致无法正确关联设备的物理位置与逻辑路径。

第二阶段：重试流程崩溃

系统尝试重新加载同一设备（FAN2），再次执行对象添加流程。
此时虽然CSR数据加载成功，但在后续处理中脚本 chip.lua 抛出致命错误：
```
ERROR: object_manage.lua(309): AddObjectsComplete failed, error: /opt/bmc/apps/hwpuroxy/lualib/chip.lua:300: table index is nil
```
这表明在尝试操作一个尚未完全初始化或已被部分清理的设备表项时，访问了空（nil）索引，导致流程中断。

第三阶段：对象被删除

由于两次尝试均失败，系统最终调用 DeleteObject 移除了该风扇对应的所有组件对象（如 Scanner_Fan_RSpeed_01010303 等）。
导致 IPMI、Redfish 等接口无法获取该风扇的传感器数据，但风扇本身仍受CPLD控制正常运行。

2. 触发场景分析

问题多发于以下操作后，符合“拓扑未就绪即尝试访问”的特征：

操作	为何导致问题
BMC升级重启	BMC启动过程中，硬件发现（hwdiscovery）与资源树构建存在时序依赖，若设备过早尝试加载而拓扑未完成，易失败。
扩展板CPLD升级	可能触发设备热重置或重新枚举，若BMC侧感知到设备变化但拓扑数据未同步更新，则注册失败。
插拔风扇	热插拔事件触发自发现流程，若事件处理太快，拓扑服务还未准备好，即出现 `topology data not exist`。

3. 软件版本因素

用户使用的是 社区版 1209 代码，此版本可能存在以下潜在缺陷：

拓扑服务（topology service）启动延迟：未充分等待拓扑构建完成即启动设备注册。
资源树加载缺乏健壮性重试机制：当前逻辑在 topology data not exist 后虽有重试，但未处理重试时的状态一致性，导致崩溃。
异常处理不完善：对 table index is nil 这类空指针访问未做防御性编程。

解决方案与建议

1. 短期规避措施

在设备加载前插入等待机制：在 hwdiscovery 模块中增加对拓扑服务就绪状态的检查，确保 topology data 存在后再进行 AddObject 操作。
增加重试机制与退避策略：对 topology data not exist 错误，采用指数退避重试（如 100ms、200ms、400ms…），最多尝试 3~5 次，避免直接进入删除流程。

2. 代码层修复建议

(1) 增强拓扑依赖检查

-- 伪代码示例：添加拓扑检查
function wait_for_topology(position)
    local max_retries = 5
    for i = 1, max_retries do
        local topo = get_topology_data(position)
        if topo then
            return true
        end
        usleep(100000 * i) -- 指数退避
    end
    log.error("Topology data still not exist after retries, position: " .. position)
    return false
end

(2) 防御性编程处理 nil 访问

在 chip.lua 的相关函数中增加判空逻辑：

-- 原始出错代码可能类似：
local value = chip_table[key].field  -- 若 chip_table[key] 为 nil，则报错

-- 修复为：
if not chip_table[key] then
    log.warn("chip data not ready for key: " .. key)
    return false
end
local value = chip_table[key].field

(3) 优化对象生命周期管理

避免重复注册或半途中断场景下状态混乱。建议：

添加 设备加载锁（per position），防止并发加载。
记录加载状态机（如 LOADING, FAILED, READY），避免重复处理。

3. 配置与验证建议

确认CSR文件完整性：检查 /opt/bmc/sr/Single_Rotator.sr 和 Dual_Rotator.sr 是否正确配置了 Connector_Fan2SingleSensor。
监控拓扑服务日志：确认 topology service 是否稳定运行，是否存在启动延迟。
启用更详细的调试日志：在 hwproxy 和 hwdiscovery 组件中打开 DEBUG 级别日志，捕获完整的加载序列。

总结

项目	内容
问题本质	风扇传感器对象因拓扑数据未就绪导致注册失败，重试时因未处理空指针访问引发崩溃，最终对象被删除。
根本原因	BMC启动或设备热插拔时序与拓扑服务不匹配，缺乏健壮的错误恢复机制。
触发条件	升级、热插拔、CPLD变更等导致设备重枚举的操作。
临时解决	重启BMC可恢复。
长期建议	修复加载逻辑，增加拓扑等待、重试机制和空值保护，提升系统健壮性。