// 此模板仅供参考，如果不适用可以修改
问题描述
客户测试发现，NPU卡连续运行一天后，卡侧会发生异常。和卡侧人员确认可能是和bmc不断去读显卡mcu日志有关，有什么办法可以去掉读日志的操作吗。
目前客户断掉bmc与显卡i2c通信之后，测试下来卡没有出问题。
软件版本：openUBMC2512-SP1
答案内容由AI生成，仅供参考：
根据您提供的回答内容，其中没有明确标有“问题总结”或“结论”等字样的章节。因此，返回空内容。
点击此处查看详细分析解答
根据您提供的上下文信息，BMC 在某些场景下会持续拉取 NPU 卡日志，这一行为已被确认是导致部分异常的根本原因。针对您提出的 “如何去掉 BMC 读 NPU 卡日志” 的问题，目前 openUBMC 2512 SP1 版本并未提供直接禁用日志拉取的配置项，但社区已有相关的讨论和可参考的缓解或解决方案。
问题确认
社区历史帖子（主题 #6382、#6381）明确分析了类似场景：
“日志排查确认，BMC 会优先持续拉取 NPU 日志，需等待全部日志读取完毕后，才会执行核温采集逻辑，因此造成温度读取延迟。” — 主题 #6382 问题描述
您客户断开 I2C 通信后卡侧恢复正常，与上述分析中 BMC 持续拉取日志导致通信压力过大的现象完全吻合。
可参考的解决途径
1. 升级至新基线版本
在主题 #6382 的回复中，用户 YOLO20317 提到：
“目前切了 2512 新基线版本，AC 后核温读取不到的问题解决了。”
这表明后续的 LTS 基线版本可能已经对日志读取策略进行了优化，直接升级到 openUBMC 2512LTS 或更高版本，可能是最直接的修复方式。
2. 调整资源轮询策略（类似 FC 卡的处理方式）
在 FC 卡光模块信息轮询的问题（主题 #6854）中，社区专家 guanyongjian 给出了原理性解释：
“我们关注的资源类型中不包含 @odata.type 为 FC.OemFCSffDiagnostic 的资源，所以在后续轮询中不会主动去轮询，只有 bma 和 bmc 第一次注册初始化所有资源的时候，才会更新一次，后续不再更新。”
同理，如果 NPU 卡 MCU 日志的读取也是通过某种资源类型（@odata.type）进行的，您可以尝试将对应的资源类型排除在监控列表之外，从而停止后续的日志拉取操作。具体实现可能需要联系 openUBMC 开发团队确认 NPU 日志对应的资源类型标识。
3. 增加 I²C 访问延迟降低频率
在 Atlas 300I 卡通过 IIC forward 读取温度失败的问题分析中，给出的解决方案是：
“增加 Chip 的写延迟设置（DrvWriteDelay）后可以正常读到温度和功率。” — 社区问题分析文档
通过为 NPU 卡对应的 Chip 对象设置适当的 DrvWriteDelay 属性（单位毫秒），可以强制 BMC 在每次读取后等待一段时间，从而降低对 NPU 卡 MCU 的连续访问压力，间接缓解因频繁日志拉取导致的卡侧异常。
建议总结
| 途径 | 具体做法 | 参考来源 |
|---|---|---|
| 版本升级 | 升级到 openUBMC 2512LTS 或后续 LTS 版本 |
主题 #6382 用户回复 |
| 资源类型过滤 | 修改配置，将 NPU 日志对应的 @odata.type 从轮询列表移除 |
主题 #6854 社区专家回复 |
| 增加读写延迟 | 在配置中为 NPU 卡 Chip 添加 DrvWriteDelay，设定合理等待时间 |
Atlas 300I 温度读取失败分析 |
建议优先尝试升级基线版本，因为这是社区中已验证能解决类似问题的途径。若仍需在 openUBMC 2512 SP1 上调整，可结合后两种方式向开发团队提交具体方案。
注意：以上建议均基于所提供的上下文（社区帖子、问题分析文档）进行归纳，具体实施效果及稳定性请结合实际环境验证。
当前没有手段能在社区版本直接修改compute发送日志，如果确实是读取日志导致的卡故障，建议咨询卡侧，按照正常说明中读取内容不应该引起器件故障。