问题描述
反复DC后出现OS侧已上电网卡的‘Hi1822_NIC1_0v75’, ‘Hi1822_NIC1_0v8’, ‘Hi1822_NIC1_1v2’, ‘Hi1822_NIC1_1v8’, ‘Hi1822_NIC1_3v3’, 'PCIe NIC1 Temp‘等传感器全为NA
环境信息
-
操作系统：[如 Ubuntu 24.04]
-
软件版本：OpenUBMC2606
-
硬件配置：[如 CPU、内存等]
重现步骤
反复DC偶然出现，出现后多次DC，OSPowerState均无变化
期望结果
系统上电后网卡传感器正常显示
实际结果
反复DC后传感器正常不正常显示
尝试过的解决方案
[列出您已经尝试过的解决方案及结果]
分析结论
1、传感器显示NA的原因是Scanner的status为3
2、Scanner的status为3的原因是PCIeNicCard_1.OSPowerState的状态为0。
3、2026-09-07 06:39:35之后触发了两次DC分别在2026-09-07 06:40:05、2026-09-07 07:24:36。PCIeNicCard_1.OSPowerState的状态依然无变化。怀疑与network_adapter组件中出现如下打印有关，导致Fructrl 属性变更触发了sig但是netwrok_adapter的协程崩溃
KunLun2280PV2_2102315QEG10S5100004_20260907-0841.tar.gz (19.4 MB)
答案内容由AI生成，仅供参考：
4. 总结
您遇到的核心问题很可能是 DC操作后，资源树中的OSPowerState属性未及时同步更新，进而导致传感器（Scanner）状态异常，最终使所有相关传感器显示NA。这既是传感器使能逻辑对电源状态依赖的缺陷，也可能涉及组件间协程同步的时序问题。建议优先参照Search Result #7和Search Result #6中的修复方案进行代码验证，同时结合Document Chunk 4中关于AC后传感器未注册的概率性现象，确认BMC各服务在电源循环后是否完全就绪。
点击此处查看详细分析解答
问题分析：反复DC后网卡传感器显示NA且OSPowerState为0
根据您提供的现象（OpenUBMC2606版本，反复DC后 ‘Hi1822_NIC1_*’ 电压/温度传感器显示NA，且 PCIeNicCard_1.OSPowerState 仍为0），结合知识库中的相关案例和代码逻辑，以下是综合分析与定位建议：
1. 现象关联的知识库依据
您遇到的问题与知识库中描述的几个已知问题高度相似，核心原因集中在以下两点：
- 电源循环（AC/DC）后传感器未注册或状态异常：知识库文档(
topic_id: 4809)明确记录了“长时间 AC，概率性出现板卡已加载，但传感器未注册，概率约 5%”，且消失的传感器正是PCIe/OCP相关（如电源、温度），这与您“反复DC后传感器全为NA”的现象一致。其根因是AC/DC操作后，系统初始化时序或传感器使能条件未满足。
- 传感器状态与电源状态（OSPowerState）绑定：您分析“Scanner的status为3原因是PCIeNicCard_1.OSPowerState为0”，知识库中“AC”实体也提到AC操作会影响系统的上下电状态和传感器初始化。同时，问题分析文档（
Search Result #6）指出网卡温度值/状态是从资源树获取的，下电后资源树属性不会更新，导致温度值显示“死值”——这与您观察到的“多次DC，OSPowerState均无变化”完全吻合，说明OSPowerState很可能也是一个资源树属性，在DC后未正确刷新。
2. 根因推测（基于知识库线索）
- 传感器使能逻辑缺陷：在“NPU卡Chip 1温度传感器显示异常”分析（
Search Result #7）中提到，Entity的下电和不在位都会导致传感器禁用，但上电时未检测在位状态，导致传感器状态错误（NoReading）。您的场景中，Scanner status为3（异常）可能是由于OSPowerState未同步更新，进而导致传感器读取路径失效。
- 协程/组件启动时序问题：您怀疑与
network_adapter组件协程崩溃有关。知识库中关于“SP680网卡槽位号错误”的案例（Search Result #4）提到，拓扑建立时因服务（skynet）启动顺序概率性异常，导致组件拿到错误信息，这与您复现步骤中“反复DC偶然出现”的随机性类似。
- Scanner_PowerGood默认值或状态获取异常：在“SP226D网卡power fail告警”案例（
Document Chunk 1）中，AC操作后networkadapter_1_01011502的powerstatus变为0并触发告警，且社区建议检查Scanner_PowerGood的默认值配置。您的Scanner_CardPowerGood（见Document Chunk 3）在强制下电后也出现了状态异常的先例。
3. 结合已知解决方案的方向
根据知识库中类似问题的解决方式，建议从以下角度排查和修正：
- 强制传感器使能条件包含“在位+上电”双重检测：参考
Search Result #7的解决方案，修改代码使Entity在上电或在位时，必须同时检测电源状态和位置信息，确保只有两个条件都满足时才使能传感器，避免OSPowerState为0时传感器仍被查询。
- 消除资源树属性持久化导致的“死值”：针对
OSPowerState和传感器温度在DC后不更新的问题，可参考Search Result #6的思路——将传感器的ReadingStatus与网卡的上下电状态用表达式绑定，在下电状态下显示固定值或标记为不可用，而不是显示过期的持久化数据。
- 排查
network_adapter组件协程稳定性：结合您日志中出现的崩溃打印，参考Search Result #4的解决方案——在拓扑建立时使用队列将拓扑建链按顺序执行，保证网卡信息（包括OSPowerState）在协程切换时被正确传递，避免因异步时序导致状态未更新。
- 检查Scanner_CardPowerGood默认配置：参考
Document Chunk 1中社区专家建议，核实Scanner_PowerGood或Scanner_CardPowerGood的默认值（如255）是否在特定电源状态下被错误触发，确保此状态值能正确反映真实的电源循环结果。
4. 总结
您遇到的核心问题很可能是 DC操作后，资源树中的OSPowerState属性未及时同步更新，进而导致传感器（Scanner）状态异常，最终使所有相关传感器显示NA。这既是传感器使能逻辑对电源状态依赖的缺陷，也可能涉及组件间协程同步的时序问题。建议优先参照Search Result #7和Search Result #6中的修复方案进行代码验证，同时结合Document Chunk 4中关于AC后传感器未注册的概率性现象，确认BMC各服务在电源循环后是否完全就绪。
