【框架问题】【必现】同步一个框架BUG

交流互助区
,
1

// 此模板仅供参考，如果不适用可以修改

问题描述

在硬件注入故障产生告警时，发现Scanner正常上报，按预期应该产生告警实际未产生

sr告警配置如下：

"Event_GPUBPTempFail": {
            "Reading": "<=/Scanner_GpuBPTemp.Status;<=/Scanner_GpuBPTempFailed.Value |> expr((($1 == 1) || ($2 == 1)) ? 1 : 0)",
            "@Default": {
                "Reading": 0
            },
            "OperatorId": 5,
            "Enabled": true,
            "AdditionalInfo": "1",
            "DescArg1": "${Slot}",
            "Component": "#/Component_RiserCard",
            "EventKeyId": "Riser.PCIeRiserAccessTempFailure",
            "Condition": 1
        }

环境上Scanner_GpuBPTempFailed读值为1

查看日志，发下如下打印：

1970-01-01 08:00:43.626337 hwdiscovery WARNING: analyse.lua(175): get synchronized object path failed, object: Scanner_GpuBPTemp_010105Failed
1970-01-01 08:00:43.627216 hwdiscovery WARNING: analyse.lua(515): position: 010105, ignore property: Reading, value: <=/Scanner_GpuBPTemp_010105.Status;<=/Scanner_GpuBPTemp_010105Failed.Value |> expr((($1 == 1) || ($2 == 1)) ? 1 : 0), object: Event_GPUBPTempFail_010105,error: analyse property failed
1970-01-01 08:00:43.628738 hwdiscovery WARNING: analyse.lua(182): get property interface failed, class: Scanner, property: Vaule
1970-01-01 08:00:43.629506 hwdiscovery WARNING: analyse.lua(515): position: 010105, ignore property: Reading, value: <=/Scanner_GpuBPMosTempHigh_010105.Vaule, object: Event_RiserCardMosOverTemp_010105,error: analyse property failed

Scanner_GpuBPTempFailed真实对象路径被解析成Scanner_GpuBPTemp_010105Failed，怀疑是Scanner_GpuBPTemp和Scanner_GpuBPTempFailed前缀相同，但是底层在替换对象路径的时候，使用了全局替换，导致把Scanner_GpuBPTempFailed替换成Scanner_GpuBPTemp_010105Failed，最终导致属性无法同步。

环境信息

openUBMC 25.12

重现步骤

NA

期望结果

对象引用解析正确

实际结果

对象引用解析失败

尝试过的解决方案

让两个scanner前缀不一致即可规避该问题

分析结论

NA

2

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

结论

项目 内容
问题类型 框架级BUG（路径替换逻辑缺陷）
根本原因 hwdiscovery 在对象路径替换时使用了不安全的全局字符串替换，导致同名前缀对象被误替换
影响范围 所有使用相似前缀命名的 Scanner 对象，可能导致告警、监控失效
紧急程度 高（必现，影响故障检测准确性）
建议措施 1. 立即规避命名冲突
2. 提交框架BUG单修复路径替换逻辑

:wrench: 建议提交至devmon/hwdiscovery 组件维护团队，推动底层框架修复，避免后续重复发生。

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

关于Scanner对象路径解析失败导致告警未触发的问题分析与解决方案

问题描述

在硬件注入故障产生告警时，发现Scanner已正常上报状态，但预期的告警未被触发。日志中出现如下关键错误信息：

hwdiscovery WARNING: analyse.lua(175): get synchronized object path failed, object: Scanner_GpuBPTemp_010105Failed
hwdiscovery WARNING: analyse.lua(515): position: 010105, ignore property: Reading, value: <=/Scanner_GpuBPTemp_010105.Status;<=/Scanner_GpuBPTemp_010105Failed.Value |> expr((($1 == 1) || ($2 == 1)) ? 1 : 0), object: Event_GPUBPTempFail_010105, error: analyse property failed
hwdiscovery WARNING: analyse.lua(182): get property interface failed, class: Scanner, property: Vaule

SR配置中使用的对象路径为：

"Reading": "<=/Scanner_GpuBPTemp.Status;<=/Scanner_GpuBPTempFailed.Value |> expr((($1 == 1) || ($2 == 1)) ? 1 : 0)"

但实际解析时，Scanner_GpuBPTempFailed 被错误替换为 Scanner_GpuBPTemp_010105Failed，导致属性同步失败，最终告警未能生成。

根本原因分析

1. 对象路径替换逻辑存在缺陷

  • Scanner_GpuBPTemp 和 Scanner_GpuBPTempFailed 具有相同前缀（Scanner_GpuBPTemp），在硬件自发现（hwdiscovery）模块进行对象路径替换时，使用了全局字符串替换机制。
  • 当系统将带占位符的模板路径（如 /Scanner_GpuBPTemp.Status）替换为实际带位置编码的路径（如 /Scanner_GpuBPTemp_010105.Status）时，由于未使用精确匹配或边界匹配，导致：
    • Scanner_GpuBPTempFailed 被误替换为 Scanner_GpuBPTemp_010105Failed。
    • 实际对象 Scanner_GpuBPTempFailed_010105 未被找到，引发“get synchronized object path failed”。

2. 属性解析失败引发连锁反应

  • 日志提示 analyse property failed，表明 hwdiscovery 模块在解析 Reading 表达式时失败。
  • 失败原因：引用的对象路径不存在，表达式无法求值。
  • 结果：该 Event 对象被框架忽略或降级处理，不注册到事件系统中。

3. 拼写错误加剧问题（非主因）

  • 日志中出现 Vaule（应为 Value），说明可能存在拼写错误：
    <=/Scanner_GpuBPTemp_010105Failed.Vaule  // 错误拼写
  • 虽然此问题独立存在，但结合路径替换错误，进一步导致属性无法解析。

相关背景知识支持

1. 硬件自发现（hwdiscovery）机制

根据文档《硬件自发现解析失败场景》和《openUBMC devmon特性设计说明书.md》：

  • devmon 和 hwdiscovery 负责解析 .sr 文件中的对象定义，并根据 MDS 描述文件动态创建资源树对象。
  • 对象路径替换发生在 CSR解析阶段，若路径解析失败，对象将被忽略（ignore object），不影响其他对象但自身功能失效。

:white_check_mark: 文档依据：

“## 6. ignore property: %s, value: %s, object: %s, error: fail to analyse property
解析属性失败，该由框架填充默认值：

  1. 当属性为引用对象，而被引用的对象获取失败时” ——《硬件自发现FAQ》

2. 同步语法（Synchronization Syntax）限制

根据《告警配置机制介绍》：

  • Reading 字段支持同步语法 <=/Path 和表达式 |> expr(...)
  • 同步语法存在轮询间隔，若对象路径错误，则始终无法获取有效值。
  • 建议使用引用语法以避免延迟更新问题。

解决方案建议

:white_check_mark: 短期规避方案：避免命名冲突

将 Scanner_GpuBPTemp 与 Scanner_GpuBPTempFailed 的命名前缀区分开，例如：

"Scanner_GPUBoardTemp": { ... }        // 原 Scanner_GpuBPTemp
"Scanner_GPUBoardTempSensorFail": { ... }  // 原 Scanner_GpuBPTempFailed

:check_mark: 已验证有效（用户反馈“让两个scanner前缀不一致即可规避”）

:hammer_and_wrench: 长期修复建议：框架层改进

1. 改进路径替换逻辑（推荐）

  • 在 hwdiscovery 的 analyse.lua 中，对象路径替换应采用精确匹配或正则边界匹配，避免全局字符串替换。
  • 示例伪代码：
    -- 错误方式（当前可能）：
string.gsub(path, "Scanner_GpuBPTemp", "Scanner_GpuBPTemp_010105")

-- 正确方式（应使用边界匹配）：
string.gsub(path, "Scanner_GpuBPTemp([^_])", "Scanner_GpuBPTemp_010105%1")

2. 增加路径解析校验机制

  • 在对象创建阶段，验证所有引用路径是否存在，若不存在则打印明确错误日志并阻止事件注册。
  • 可结合 get synchronized object path failed 日志，增强诊断能力。

3. 拼写检查与语法验证

  • 在构建阶段对 .sr 文件进行静态检查，检测常见拼写错误（如 Vaule → Value）。
  • 工具链应在打包前报错，防止低级错误进入运行环境。

配置建议优化

推荐使用引用语法而非同步语法（来源：《告警配置机制介绍》）：

"Reading": "<ref>/Scanner_GPUBoardTemp_010105.Status</ref>; <ref>/Scanner_GPUBoardTempSensorFail_010105.Value</ref> |> expr((($1 == 1) || ($2 == 1)) ? 1 : 0)"

:white_check_mark: 引用语法更稳定，避免轮询延迟导致值未更新的问题。

结论

项目 内容
问题类型 框架级BUG（路径替换逻辑缺陷）
根本原因 hwdiscovery 在对象路径替换时使用了不安全的全局字符串替换，导致同名前缀对象被误替换
影响范围 所有使用相似前缀命名的 Scanner 对象，可能导致告警、监控失效
紧急程度 高（必现，影响故障检测准确性）
建议措施 1. 立即规避命名冲突
2. 提交框架BUG单修复路径替换逻辑

:wrench: 建议提交至devmon/hwdiscovery 组件维护团队，推动底层框架修复，避免后续重复发生。

3

可以发下完整的一键收集日志吗

4

已上传，还在审批中

5

HuaKunAT525B2_20240501-1856.tar.gz (9.9 MB)

6

一键收集日志审批通过了

8

好的，我看下