下级SR中{slot}的值与上级connnector的slot字段不一致如何解决

Hardware SIG
1

环境中connector的slot值为2，而下级SR对象中获取的${slot}为8，两方不一致，许多显示相关受影响，有无好的解决方法

1、connector

        "Connector_cage2": {
            "Bom": "14100513",
            "Slot": "<=/Scanner_Cage2_Type.Value |> expr($1 == 1 ? 2 : 8)",
            "Position": 9,
            "Presence": "<=/Scanner_cage2_Presence.Value",
            "Id": "",
            "AuxId": "",
            "Buses": [
                "I2c_2",
                "I2cMux_chan1",
                "I2c_4"
            ],
            "SystemId": 1,
            "SilkText": "cage2",
            "IdentifyMode": 3
        },

2、下级SR使用{slot}的对象

"PcieAddrInfo_NVMe_7": {
            "ComponentType": 2,
            "ControllerIndex": 0,
            "ControllerType": 0,
            "ContainerSlot": "${Slot}",
            "GroupPosition": "PcieAddrInfo_NVMe_7_${GroupPosition}",
            "ContainerUID": "00000001030302084145",
            "Location": "HddBackplane${Slot}",
            "ContainerUnitType": "SEU"
        },

3、实际环境中connector的属性

image
image396×429 7.23 KB

4、下级SR里对象的属性

image
image534×517 9.09 KB

AC后OCP网卡从OCP5变成OCP1，且读不到网卡温度，传感器事件有传感器降级告警
2

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

下级SR中${Slot}值与上级Connector的Slot字段不一致问题分析与解决方案

根据您提供的信息，当前环境中存在上级Connector的Slot值为2，而下级SR中${Slot}解析为8，导致二者不一致，进而影响了诸如Location、ContainerSlot等依赖Slot值的配置项，最终可能引发硬件位置显示错误、PCIe拓扑错误或管理功能异常等问题。以下是对此问题的详细分析与解决建议。

:magnifying_glass_tilted_left: 问题定位

1. 现象总结

  • 上级Connector (Connector_cage2):

    "Slot": "<=/Scanner_Cage2_Type.Value |> expr($1 == 1 ? 2 : 8)"
    • 此处Slot是一个表达式，根据Scanner_Cage2_Type.Value的值动态选择为2或8。
    • 实际运行中，系统日志显示Slot=2，符合预期。

  • 下级SR对象 (PcieAddrInfo_NVMe_7):

    "ContainerSlot": "${Slot}",
"Location": "HddBackplane${Slot}"
    • 动态使用${Slot}变量进行填充。
    • 但实际下级对象中ContainerSlot=8，Location=HddBackplane8，说明${Slot}在加载时被解析成了 8。

:puzzle_piece: 根本原因分析

结合知识库和SR加载机制，可以判断该问题的核心在于：

:white_check_mark: 问题根源：${Slot}在SR解析时继承自上级Connector加载时的变量上下文（变量栈），但该变量可能被错误地缓存或提前解析为表达式的“备选分支”值（8）。

具体分析如下：

  1. ${Slot}是动态变量：

    • ${Slot}并非直接来自Connector.Slot属性，而是由上级Connector对象在加载下级SR时，将其自身的属性（如Slot, SystemId等）作为变量注入到下级SR的解析上下文中。
    • 也就是说，${Slot}获取的是加载时刻上级Connector对象的实际Slot属性值。

  2. 表达式执行时机与变量捕获不一致：

    • 表达式：
      "Slot": "<=/Scanner_Cage2_Type.Value |> expr($1 == 1 ? 2 : 8)"
      是在Connector对象初始化时动态计算的。
    • 但在某些异常场景（如历史配置残留、变量缓存未刷新、多次加载尝试），下级SR可能：
      • 在表达式尚未完全求值前就启动加载；
      • 或基于错误的临时上下文（比如之前Type为8的情况）捕获了${Slot}=8；
      • 导致下级SR固化错误的Slot值。

  3. 与知识库证据吻合：

    • 从搜索结果中的【CSR 语法汇总指南】可知：

      ${变量名}：支持将上级Connector对象的属性值作为参数，替换下级加载组件的SR中对象的变量。

    • 从【硬件自发现解析流程】可知：

      变量替换发生在组件加载时，若上级Connector未正确完成初始化，可能导致下级获取到错误上下文。

    • 从文档【鲲鹏模组适配约束FAQ】也指出：

      SR文件加载失败可能导致拓扑信息错误、上下电异常。

:white_check_mark: 解决方案

:white_check_mark: 方案一：确保表达式求值完成后再加载下级SR（推荐）

目标：确保${Slot}在下级SR加载前，已经正确计算为2，并作为上下文传递。

操作步骤：

  1. 确认Scanner_Cage2_Type.Value当前真实值为1（保证表达式逻辑正确）。

    lsprop Scanner_Cage2_Type Value

    输出应为 1。

  2. 检查Connector_cage2加载状态是否为LoadStatus=1（已加载完成）。

    lsprop Connector_cage2_010103 LoadStatus

    若为 0，则说明加载未成功或中断过。

  3. 手动触发卸载并重新加载：

    bmc-ctl --unload Connector_cage2_010103
bmc-ctl --load Connector_cage2_010103

    确保下级SR在上级Connector完全初始化后再加载。

  4. 验证下级对象是否重建且ContainerSlot为2：

    lsprop PcieAddrInfo_NVMe_7_01010309 Containerslot
lsprop PcieAddrInfo_NVMe_7_01010309 Location

:white_check_mark: 方案二：避免使用表达式动态赋值Slot（更稳健做法）

Slot作为硬件位置标识，本质应为静态、确定值。使用条件表达式赋值容易引发歧义和上下文混乱。

建议重构：

  • 若cage2和cage类型由硬件决定，建议改由**Id或Bom`区分两种SR文件**。

推荐做法：

  1. 拆分为两个独立的SR文件：

    • 14100513_type1.sr → 用于cage2，Slot=2
    • 14100513_type8.sr → 用于cage8，Slot=8

  2. 在Connector中基于Scanner_Cage2_Type.Value选择加载不同SR：

    "Presence": "<=/Scanner_cage2_Presence.Value",
"Id": "<=/Scanner_Cage2_Type.Value |> expr($1 == 1 ? 'TYPE2' : 'TYPE8')",
"IdentifyMode": 1

    并配置：

    • TYPE2 对应 14100513_type1.sr
    • TYPE8 对应 14100513_type8.sr

  3. 每个SR中使用静态Slot=2或Slot=8，无需${Slot}动态传递。

:white_check_mark: 优势：避免动态上下文污染，提升系统稳定性。

:white_check_mark: 方案三：在下级SR中不依赖${Slot}，改用硬编码或独立字段

若无法重构SR，可考虑在PcieAddrInfo_NVMe_7中不使用${Slot}，而是：

"ContainerSlot": 2,
"Location": "HddBackplane2"

适用于固定配置场景，但牺牲了模块化灵活性。

:warning: 风险与规避建议

风险 说明 规避措施
变量上下文污染 历史加载残留导致变量错误继承 执行bmc-ctl --unload清除旧对象
表达式未求值 动态表达式未完成前被引用 确保LoadStatus=1后再使用
Slot冲突 两个设备使用相同Slot 检查系统中所有SlotNumber唯一性

:white_check_mark: 总结与建议

建议项 说明
根本原因 ${Slot}继承自上级Connector，但因表达式未及时求值或上下文污染导致继承错误值
首选方案 方案二：拆分SR文件，按类型加载，避免动态Slot
临时解决 手动卸载并重载Connector，确保加载顺序正确
最佳实践 Slot应为静态配置，避免在关键位置使用动态表达式赋值

:wrench: 强烈建议：对于涉及物理槽位的Slot字段，应通过静态SR配置或**Bom/Id区分不同硬件形态**，而非依赖运行时表达式动态决定，以确保系统稳定性和可维护性。

如有必要，可提供更多日志（如hwdiscovery日志）进一步分析加载流程。

相关链接：

  1. 【PSR】有4个同一UID的UnitConfiguration配置，出现概率性匹配到不同的配置
  2. M.2 NVMe硬盘是适配问题
  3. 系统管理-其他-PCIE卡页面槽位号和CPU归属信息不同步
  4. 网卡的rootBDF和Bus Device Function(BDF)的区别
  5. 硬件自发现解析流程 | 文档中心 | openUBMC
3
  1. ${Slot}这种语法我们目前仅支持静态属性，即在对象初始化时这个值就固定了，后续并不会因为上一级Slot的变化而变更，
  2. 因此我理解你这个现象是因为01010309对象添加时slot还是8，后续因为配置同步010103Connector对象的slot又变为了2，但01010309对象的slot并不会随之改变。
4

如图1所示是CLU CSR 1.24版本和1.27版本的对比，1.27版本修改从固定slot2 改为动态获取 Scanner_Cage2_Type下的Value值，图2的值是BMC启动完成后抓取的值，目前怀疑在加载CSR时，Scanner_Cage2_Type的属性未更新，导致slot槽位变为了8

00003ca76a8f6f18f3ffcd94558401aa
00003ca76a8f6f18f3ffcd94558401aa1787×474 56.3 KB

1d093df972940a4889ca2ccbbe2a96c2
1d093df972940a4889ca2ccbbe2a96c2486×419 16 KB

5

Scanner_Cage2_Type的硬件值是固定的，不会变的吗？判断错误是因为使用了Scanner的默认值导致slot不符合预期吗？如果是这样你可以把Connector的在位关联上Scanner的状态，确保状态为0再加载，状态为0表示Scanner从硬件读值完成。

6

目前看是错误的使用了默认值导致的，等正常从硬件获取的时候，已经加载完成了