疑似 OCP 相关连接器 Position 重复导致 OCP 传感器名称混乱

kunlun_xiongzirui · 2026 年2 月 25 日 09:34

问题描述

搭载双 OCP，跑长时间 BMC 重启，7% 概率出现 OCP 传感器名称重复的现象

发现问题现象发生时，OCP 连接器变成了奇怪的样子：

正常情况下，OCP 连接器是长这样的：

观察日志，伴有 position 冲突打印：

硬件 CSR 中，存在两个 Position 完全相同的连接器：

想确认：

1、硬件 CSR 里这里的 Position 冲突，是刻意设计的，还是就是有问题；

2、传感器名称重复的现象，能否确认就是该连接器 Position 冲突导致的问题？

环境信息

拓展板 UID：00000001010302044492

CSR 版本：3.45

ubmc_assistant · 2026 年2 月 25 日 09:40

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

总结

问题	回答	评级
1. CSR 中 `Position` 冲突是否为设计问题？	是错误配置，违反系统规范	高危
2. 是否导致 OCP 传感器名称混乱？	极大概率是根本原因，引发加载竞态与对象错乱	确认

强烈建议立即修复 CSR 中的 Position 重复问题，这是保障 BMC 硬件发现稳定性的基础。

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

关于 OCP 连接器 Position 冲突及传感器名称混乱问题的分析

根据您提供的详细日志、配置信息和现象描述，结合知识库中的技术规范与系统机制，现对您提出的两个核心问题进行专业分析与结论说明。

问题一：硬件 CSR 中的 `Position` 冲突是刻意设计还是存在设计问题？

结论：属于配置错误，非刻意设计

在 BMC 系统的硬件自发现框架中，同一 CSR 文件内的多个 Connector 对象必须保证 Position 属性唯一，这是系统对象加载与命名机制的基本约束。

依据分析：

官方配置规范明确指出：
- 根据《板卡适配指南》（文档 ID 9）：
  
  “同一个 CSR 文件中的任意两个连接器 Position 不能重复”
- 《CSR配置字典之Connector类》（文档 ID 5）进一步强调：
  
  “Position必须在同一CSR中保持唯一性，建议按实际物理位置递增配置”
系统行为验证了该规则的重要性：
- 日志中清晰记录了如下错误：
```
add connector Connector_OCP_1_0101 failed, duplicated group position: 010107, existing connector: Connector_OCP_1TianChi_0101
```
  此表明系统检测到 GroupPosition = 010107 已被占用，新连接器加载失败，直接触发异常。
实际配置问题：
您的 CSR 配置中存在两个 Position: 7 的连接器：
```
"Connector_OCP_TianChi": { "Position": 7, ... }
"Connector_OCP_1":       { "Position": 7, ... }
```
- 虽然两者的识别模式不同（IdentifyMode=3 vs IdentifyMode=2），但 Position 值重复仍然违反了系统唯一性要求。
- 尤其关键的是，这两个连接器共享相同的 Bom 和 Slot，极易造成加载冲突。

正确设计原则：

若需支持多种识别模式（如兼容旧款或调试用途），应通过：
- 不同 CSR 文件按优先级加载
- 或使用动态条件判断逻辑（如 Presence 表达式）控制加载路径
绝不应在同一 CSR 中并列定义多个相同 Position 的 Connector 对象

问题二：传感器名称混乱（如 OCP1 Temp、OCP2 OP Temp 重复）是否由 Position 冲突导致？

结论：高度可能直接由该 Position 冲突引发

尽管传感器名称本身来源于 ThresholdSensor 等对象的命名逻辑，但其对象创建、属性继承和注册过程严重依赖于 Connector 正确加载与 GroupPosition 的正确生成。

根本原因分析链：

步骤	机制	影响
	`Position` 重复 → `GroupPosition` 冲突	两个 OCP 连接器试图使用相同的 `GroupPosition: 010107`
	系统仅允许注册一个 `GroupPosition`	后加载的 `Connector_OCP_1_0101` 被丢弃或部分加载
	对应 `.sr` 文件未成功加载或状态不一致	导致 `OCPCard_1`、`OCPCard_2` 对象信息错乱
	Sensor 命名基于 `DeviceName`, `Slot`, 或 `Position`	出现命名异常（如 `OCP2 OP Temp` 重复、`na`）
	多次重启后随机加载顺序变化	造成 7% 概率出现的问题，符合“竞争条件”特征

关键证据支撑：

日志中出现非法连接器名：
```
Connector_OCP_dTianChi_0101
```
表明字符串拼接逻辑出错，极可能是 ObjectGroup 重命名机制因 GroupPosition 冲突而生成了异常名称。
正常连接器有明确来源路径：
```
SourcePath : /opt/bmc/sr/14220247_14e416d7_1f242013.sr
```
而异常连接器无此字段，说明 .sr 未正确加载。
7% 的复现概率典型于加载竞态：
- 7% 接近随机化启动顺序下特定路径被选中的小概率事件
- 正是由于两套 OCP 配置共存、依赖动态 Presence 判断，导致状态不稳定
OCP 传感器依赖组件健康状态：
- 实体 OCPCard_1 健康度由 Component_OCPCard 管理
- 而 Component_OCPCard 依赖于 PCIeDevice_1 和 Connector 的正确定位
- Connector 加载失败 → Component 信息缺失 → 传感器注册异常

建议解决方案

1. 修正 CSR 配置（最根本措施）

将两个 Position=7 的连接器进行区分处理，推荐方案如下：

{
  "Connector_OCP_TianChi": {
    "Bom": "14220247",
    "Slot": 1,
    "Position": 7,
    "IdentifyMode": 3,
    "Presence": "<=/Scanner_SerdesLom1Pres.Value; ... ?> expr(($1 == 1 && $2 == 1) ? 1 : 0)"
  },
  "Connector_OCP_1_backup": {
    "Bom": "14220247",
    "Slot": 1,
    "Position": 77,  // 修改为非冲突值
    "IdentifyMode": 2,
    "Presence": 0   // 仅用于兜底，不主动启用
  }
}

说明：主路径使用 IdentifyMode=3（天池标准），备份路径置于不同 Position，仅作兼容。

2. 强化 Presence 判断逻辑

确保 IdentifyMode=3 的连接器能可靠获取 Presence 状态，避免与低优先级模式抢资源。

3. 使用工具验证配置合法性

使用 mdbctl 或 hwdiscovery 调试工具检查：

% lsobj Connector | grep OCP
% getprop Connector_OCP_TianChi Position

确认无重复 GroupPosition 生成。

4. 增加日志监控项

在生产环境中添加对以下日志的监控：

hwdiscovery ERROR: add connector .* failed, duplicated group position

一旦触发立即告警，定位问题配置。

总结

问题	回答	评级
1. CSR 中 `Position` 冲突是否为设计问题？	是错误配置，违反系统规范	高危
2. 是否导致 OCP 传感器名称混乱？	极大概率是根本原因，引发加载竞态与对象错乱	确认