// 此模板仅供参考，如果不适用可以修改
问题描述
拔出网卡光模块后，光模块对象信息仍然显示在位，Presence=1
环境信息
- 软件版本： OpenUBMC2509
实际结果
没有插光纤线时上报了告警，拔出光模块后告警也不会消失
答案内容由AI生成，仅供参考：
光模块拔出后在位信息未更新及告警不消失问题分析
问题描述
当网卡光模块被物理拔出后，系统中对应的光模块对象信息仍然显示为“在位”（Presence=1），并且之前因无光纤连接触发的告警未能自动清除。
根据提供的系统信息：
- 光模块对象
OpticalModule_2_010108的Presence属性仍为1 - 系统持续上报“Abnormal Rx signal of optical module”（光模块接收信号异常）的严重告警
- 即使拔出光模块，该告警也无法自动消失
根本原因分析
1. 在位状态检测机制失效
光模块的在位状态通常通过以下方式检测：
- 硬件级检测：通过检测光模块插槽的机械开关或电气接触信号。
- 协议级检测：通过 SMBus/I2C 总线与光模块通信，判断是否能读取其 EEPROM 信息。
从当前现象来看，系统虽然判断 Presence=1，但 Accessible=0、Manufacturer 等字段无法正常获取或为空，表明光模块实际已不可访问，说明其已被移除。然而 Presence 状态未同步更新，说明：
光模块在位检测逻辑与实际通信状态脱节，未进行状态联动刷新。
支持依据：
Accessibility=0表示无法访问模块ModuleState=255是默认值，表示未进入正常工作状态TX/RX Current/Power均为 0，无有效数据交互
符合“物理拔出”后的特征。
2. 告警清除机制设计缺陷
告警系统应当具备基于对象生命周期的动态管理机制，即：
- 当光模块被拔出时，应自动清除与其相关的所有传感器告警。
- 当模块重新插入后，再重新采样并判断是否触发新告警。
但当前系统中：
告警未与
Presence状态绑定联动，导致模块移除后告警持续存在。
这属于典型的“孤悬告警（Hanging Alarm）”问题。
支持依据：
文档明确指出：
“Event仅对Reading值负责，Event是通过监听Reading值触发告警”
这意味着：
- 若无主动清除机制，即使引发告警的实体已不存在，事件仍会持续存在
- 需由上层逻辑判断模块
Presence状态来决定是否屏蔽或清除告警
3. 检测策略未遵循“去抖 + 主动探测”机制
理想情况下，应在光模块状态变化时执行：
- 去抖处理：防止插拔过程中的瞬时噪声影响判断
- 主动探测链路：
- 检查是否可通信（SMBus）
- 尝试读取模块厂商信息等静态数据
- 状态更新：综合判断 Presence 状态
但在本案例中：
- 尽管
Presence=1，但无任何有效数据返回
表明系统可能仅依赖初始化状态或静态寄存器值，并未执行动态探测。
相关系统机制说明
光模块在位检测设计（应有机制）
来自《openUBMC 182x大板管理特性设计说明书》中定义的新增功能：
【新增】汇聚光模块查询信息：
- 光模块在位状态：光模块是否在位（在位/不在位）
- 光模块静态信息：厂商名称、部件名称、序列号等
- 光模块动态信息：温度、电压、功率、电流等
【新增】获取光模块在位状态：快速查询单个光模块的在位状态
此外，bmc.kepler.Systems.OpticalModule 接口包含：
| Presence | U8 | 只读 | 光模块是否在位 |
| Accessible | U8 | 只读 | 光模块是否可访问 |
两者应联合判据：
Presence = 在位 且 Accessible = 1 才表示真正有效的在位状态
理论上的正确处理流程
graph TD
A[定时检测光模块状态] --> B{Presence = 1?}
B -- 否 --> C[标记为离线, 清除所有相关告警]
B -- 是 --> D{Accessible = 1?}
D -- 否 --> C
D -- 是 --> E[继续监测各项指标]
E --> F{是否超阈值?}
F -- 是 --> G[触发相应告警]
F -- 否 --> H[保持正常状态]
解决方案建议
方案一：修复 Presence 判断逻辑
修改 network_adapter 服务中的在位检测逻辑，改为：
- 先读取
Presence引脚状态 - 再尝试通过 SMBus 读取模块基本数据（如厂商信息）
- 仅当两者均为有效时，才设置 Presence = 1
修改文件：
network_adapter.lua中与OpticalModule.Presence相关逻辑
方案二：告警依赖 Presence 和 Accessible 状态
在告警生成逻辑中加入前置条件校验：
if module.Presence == 1 and module.Accessible == 1 then
-- 允许检测读数并判断是否告警
else
-- 强制清除与该模块关联的所有传感器告警
clear_all_optical_module_alarms(module_id)
end
方案三：增加“热插拔监控任务”
在 network_adapter 中增加一个周期性热插拔检测任务（如每 5~10 秒一次），执行以下操作：
- 对每个端口尝试发起 SMBus 通信
- 若失败超过 N 次（如 3 次），则判定模块已拔出
- 强制更新
Presence=0并清除所有关联状态与告警
参考配置与开发指引
推荐检查点清单
| 检查项 | 是否符合 |
|---|---|
Presence 是否仅依赖硬件引脚？ |
应结合通信能力 |
Accessible 是否被用于告警抑制？ |
应启用 |
| 是否存在模块移除时的告警清除逻辑？ | 必须补充 |
是否使用 SMBus 主动探测模块存在？ |
建议加入 |
总结
| 问题 | 原因 | 建议措施 |
|---|---|---|
拔出后 Presence=1 |
检测机制不完整，仅依赖初始状态 | 联动 SMBus 通信结果 |
| 告警无法清除 | 告警未绑定 Presence 生命周期 | 增加 Presence 条件判断 |
| 数据残留 | 系统未释放对象状态 | 实现对象回收机制或定时清理 |
结论：当前行为 不符合预期设计规范。系统应在光模块拔出后正确更新
Presence=0并清除相关告警。建议结合Presence与Accessible属性，实现更精确的状态管理机制。
相关链接：
通过带外IPMI命令获取光模块信息的流程里确实没判断光模块不在位的情况，建议在network_adapter仓的om_cpu.lua文件中如下代码段加上不在位并reset获取信息的逻辑
if rsp and rsp.Status == 0x00 then
orm_obj.Presence = 1
else rsp and rsp.Status == 0x02
// 示例新增代码，判断是否需要防抖等异常处理，协议里规定0x02代表光模块不在位
reset_diagnostic_info(orm_obj)
log:info("optical module not present")
end