RAID卡下硬盘协商速率显示为2.5Gbps，storcli显示22.5Gbps，枚举映射冲突

交流互助区
1

WebUI存储管理页面，RAID卡下 所有 物理盘的"协商速率"均显示为 2.5 Gbps，storcli显示22.5Gbps，疑似枚举映射冲突

image
image1432×394 82.5 KB

image
image1268×798 329 KB

image
image1270×803 181 KB

环境信息

  • 软件版本：[OpenUBMC2512]

数据链路：

固件 → storelib(闭源) → sl.c:GetPDInfo → sl_pd.c:FillPDInfo → Lua枚举表 → WebUI

固件通过 MR_DCMD_PD_GET_INFO 返回 MR_PD_INFO 结构， linkSpeed 字段注释为 negotiated link speed (MR_PD_SPEED)

内部枚举 SML_PD_SPEED_TYPE_E 定义如下（sml_physical_drive.h）：
typedef enum _tag_pd_speed_type {
PD_SPEED_UNDEFINED = 0, // 0
PD_SPEED_1P5G, // 1 - SAS 1.5G
PD_SPEED_3G, // 2 - SAS 3G
PD_SPEED_6G, // 3 - SAS 6G
PD_SPEED_12G, // 4 - SAS 12G
PD_SPEED_2P5G, // 5 - 2.5G (PCIe Gen1) ← 这里！
PD_SPEED_5G, // 6 - 5G (PCIe Gen2)
PD_SPEED_8G, // 7
…
PD_SPEED_22P5G = 20, // 20 - SAS 22.5G
} SML_PD_SPEED_TYPE_E;

Lua 侧映射（common_def.lua）：

PD_PHYSICAL_SPEED = {
[5] = “2.5 Gbps”,
…
[20] = “22.5 Gbps”
}

仓库自带的 mr.h中 MR_PD_SPEED 枚举只定义了 0~4（对应1.5G/3G/6G/12G）:

typedef enum _MR_PD_SPEED {

MR_PD_SPEED_UNKNOWN = 0, // not defined

MR_PD_SPEED_1p5G = 1, // 1.5Gb/s - SATA 150

MR_PD_SPEED_3G = 2, // 3.0Gb/s

MR_PD_SPEED_6G = 3, // 6.0Gb/s

MR_PD_SPEED_12G = 4, // 12.0Gb/s

MR_PD_SPEED_PCIE_2_5GT = 0x80, // 2.5GT/s

MR_PD_SPEED_PCIE_5GT = 0x81, // 5GT/s

MR_PD_SPEED_PCIE_8GT = 0x82, // 8GT/s

MR_PD_SPEED_PCIE_16GT = 0x83 // 16GT/s

} MR_PD_SPEED;

尝试过的解决方案

根据枚举值主观判断返回的数据枚举值是5（5对应2.5G，符合WebUI显示），修改/home/workspace/storage/src/lualib/drive/drive_object.lua：

-- 支持获取物理盘的接口速率（最大速率）

self.CapableSpeedGbs = (pd_info.device_speed == 5) and 20 or pd_info.device_speed

-- 支持获取物理盘的连接速率（协商速率）

self.NegotiatedSpeedGbs =(pd_info.link_speed== 5) and 20 or pd_info.link_speed

编译升级后Web界面硬盘协商速率显示：22.5Gbps

想请教各位：

1.固件返回的协商速率枚举值值是 5吗？ 我查了目前的 mr.h， MR_PD_SPEED 枚举只有 0~4（1.5G/3G/6G/12G）+ 0x80 起的 PCIe 速率，5 是保留值，没有 22.5G 定义（上面有代码）。

2.为什么 openUBMC 内部 SML 枚举把 5 定义为 2.5G？ 这个枚举表看起来是 SAS 速率（0 4）和 PCIe/NVMe 速率（5 19）混在一张表里，5 被占给了 2.5G（PCIe Gen1），而 22.5G 被追加到 20。这样固件枚举和内部枚举在 5 上冲突，导致 SAS4.0 的 22.5G 被误映射成 2.5G。这个设计是否合理？有没有官方说明？

3.我的分析有没有什么问题？如何修改才符合社区规范？

2

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

3. 结论

由于当前知识库缺少 SML_PD_SPEED_TYPE_E、MR_PD_SPEED 等关键枚举定义的详细内容，无法给出确切的固件返回值、设计合理性或官方的规范修改步骤。您自行验证的硬编码修复在功能上有效，但从社区规范性角度，建议：

  • 查阅openUBMC源码仓库中 storage/src/lualib/common_def.lua 和 include/sml_physical_drive.h 等文件，确认枚举定义是否已更新；
  • 参考已合并的相似问题补丁（如RAID卡适配指导中提及的适配流程）；
  • 在社区论坛中发起讨论，确认固件实际返回值及其对应关系。

如有进一步的知识库资源（如社区历史帖子、官方设计文档），可补充后再进行更完整的分析。

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

根据提供的知识库上下文，未能直接找到关于 SML_PD_SPEED_TYPE_E 枚举定义、MR_PD_SPEED 枚举映射冲突以及 2.5Gbps / 22.5Gbps 速率转换的明确官方说明。以下分析仅基于您问题中给出的信息，并尽可能引用上下文中的相关内容进行关联说明。

1. 关于您提出的三个问题

问题1：固件返回的协商速率枚举值是否为 5？

  • 知识库中未包含固件侧 MR_PD_SPEED 枚举的完整定义或具体的日志证据，无法直接确认返回值为5。
  • 但从您提供的修改效果（将 link_speed==5 映射为20后Web显示22.5Gbps）反向推断，固件很可能返回了5，而openUBMC内部枚举将5视为 PD_SPEED_2P5G（2.5G），导致显示错误。

问题2：为什么openUBMC内部 SML 枚举把5定义为2.5G？

  • 上下文未解释该枚举的设计意图或官方说明。
  • 相关的 RAID Card 实体描述中仅提到支持 RAID 0/1/5/6/10/50/60 等级别，以及通过 PCIe 或 MCTP 协议通信，未涉及速率枚举的混合布局。
  • 您的分析（SAS速率和PCIe速率被混在同一张表里，5被占用给2.5G，22.5G被追加到20）是合理的推断，但无法从当前知识库中验证。

问题3：您的分析是否存在问题？如何修改才符合社区规范？

  • 您通过在 drive_object.lua 中硬编码 (pd_info.link_speed==5) and 20 or pd_info.link_speed 解决了显示问题，但这种方法：
    • 只修复了枚举值5 → 20的映射，若其他枚举值（如6、7等）也存在冲突则需要逐一处理；
    • 可能不如在底层枚举定义（如 common_def.lua 或 sml_physical_drive.h）中统一修正更符合规范。
  • 知识库中未提供社区修改规范的具体要求，但相关的 RAID卡适配指导（Search Result 3）指出：获取RAID卡信息后，通过 on_update:on 函数触发刷新数据，并提到底层通信支持I2C和MCTP over PCIe模式。这说明存储层的数据映射应遵循组件内的统一适配逻辑，而非在业务层硬编码。

2. 知识库中可参考的相关背景

  • RAID卡与BMC交互存在显示问题：知识图谱中记录 BMC Web → SAS 3152 关系表明“SAS 3152 RAID卡在BMC Web界面配置后无法显示详细信息”；BMC Interface → RAID Card 关系指出“RAID卡报告为0，BMC未能检测到存储控制器硬件”。这些说明BMC对RAID卡信息的解析存在已知缺陷，速率映射错误可能是其中之一。

  • 枚举映射的数据链路：问题中提到的 固件 → storelib → sl.c:GetPDInfo → sl_pd.c:FillPDInfo → Lua枚举表 → WebUI 链路与知识库中 RAID卡适配指导 描述的流程一致。该指导提到：“pcie_device识别到对应的RAID卡csr后，会调用storage模块，获取RAID卡信息”。您遇到的枚举冲突位于Lua映射表环节。

  • 部分枚举值含义示例：知识图谱中的 ControllerType 实体展示了类似的枚举映射（如0→PCIeCore、2→SAS等），说明系统中存在多种枚举表，且可能因版本或平台不同而存在不一致。

3. 结论

由于当前知识库缺少 SML_PD_SPEED_TYPE_E、MR_PD_SPEED 等关键枚举定义的详细内容，无法给出确切的固件返回值、设计合理性或官方的规范修改步骤。您自行验证的硬编码修复在功能上有效，但从社区规范性角度，建议：

  • 查阅openUBMC源码仓库中 storage/src/lualib/common_def.lua 和 include/sml_physical_drive.h 等文件，确认枚举定义是否已更新；
  • 参考已合并的相似问题补丁（如RAID卡适配指导中提及的适配流程）；
  • 在社区论坛中发起讨论，确认固件实际返回值及其对应关系。

如有进一步的知识库资源（如社区历史帖子、官方设计文档），可补充后再进行更完整的分析。

3

代码链路已全部核实。以下是对帖子三个问题的回答。

问题分析（基于 storage 仓代码核实）

关键证据链

1. LSI 适配层是“直接透传”，没有做枚举转换 — [sl_pd.c:2302-2303](file:///home/workspace/storage/src/lualib-src/sml/sml_lsi/src/sl_pd.c#L2302-L2303)

pPDinfo->pdinfo.device_speed = PdInfo->deviceSpeed;
pPDinfo->pdinfo.link_speed   = PdInfo->linkSpeed;

2. 而其他两家厂商适配层都有转换函数，映射到统一 SML 枚举：

  • PMC 路径 [sc_pd.c:377-401](file:///home/workspace/storage/src/lualib-src/sml/sml_pmc/src/sc_pd.c#L377-L401)：parse_sas_link_rate() 把 PMC 的 phy 速率码 0x08~0x0C 转成 SML 枚举，其中 case 0x0C: link_rate = PD_SPEED_22P5G（22.5G 明确映射到 20）
  • 海思路径 [hr_pd.c:341](file:///home/workspace/storage/src/lualib-src/sml/sml_hrdt/src/hr_pd.c#L341)：parse_link_speed() 同样有转换

3. Lua 层映射表 [common_def.lua:1067-1089](file:///home/workspace/storage/src/lualib/common_def.lua#L1067-L1089)：PD_PHYSICAL_SPEED[5]='2.5 Gbps'、[20]='22.5 Gbps'，与 SML_PD_SPEED_TYPE_E 一一对应。

回答问题 1：固件返回的协商速率枚举值是 5 吗？

是的，你的实验已证明。 证据闭环：

  • 你把 link_speed == 5 → 20 后 WebUI 显示 22.5Gbps → 固件返回了 5
  • storcli 走同一 storelib 的 MR_DCMD_PD_GET_INFO 显示 22.5Gbps → 固件枚举里 5 就是 22.5G
  • 仓内 mr.h/storelib.h 不在源码里（闭源 SDK，sl_pd.c:22 #include "lsi/storelib.h"），你手里的 mr.h 是旧版 SDK 头文件（只定义 0~4 + 0x80 起 PCIe 速率），新固件已扩展 MR_PD_SPEED_22P5G = 5。头文件滞后于固件是常见情况，建议向 Broadcom/板卡厂商索要与固件匹配的新 storelib 头文件确认。

回答问题 2：内部枚举为什么 5 = 2.5G？设计合理吗？

SML_PD_SPEED_TYPE_E 是跨三家 RAID 厂商的统一抽象枚举（LSI/PMC/海思都输出到它）：0~4 = SAS 传统速率，5~19 = PCIe/NVMe 速率（供 NVMe 路径 nvme_max_speed2enum 使用），22.5G 后来追加在 20。

设计本身合理，真正的缺陷是 LSI 适配层（sl_pd.c）缺失了转换层：它假设固件枚举值与 SML 枚举恰好重合（0~4 历史上确实重合），直接透传。而固件按顺序扩展（4→5=22.5G），内部枚举按尾部追加（20=22.5G），两种扩展策略在 5 上撞车。PMC/海思路径因为做了显式转换（PMC 的 0x0C→PD_SPEED_22P5G），不受影响。

回答问题 3：你的分析有问题吗？怎么改符合社区规范？

根因分析完全正确，但修改位置不符合分层规范：在 [drive_object.lua:1563-1565](file:///home/workspace/storage/src/lualib/drive/drive_object.lua#L1563-L1565) 业务层打 (x == 5) and 20 or x 补丁，问题：

  1. 只修了一个消费点，pd_info.link_speed 原始错误值仍会流向其他消费方（如 collect 日志、其他读取 pd_info 的路径）
  2. 魔法数字 5→20 散落在业务层，固件再扩展（如 24G、32G SAS）时还要到处加补丁
  3. 枚举翻译属于厂商适配层职责，仓内已有成熟模式可循

规范修改方案：在 sl_pd.c 的 FillPDInfo 加转换函数（对齐 sc_pd.c/hr_pd.c 的既有模式）：

/* 固件 MR_PD_SPEED 枚举 -> 内部 SML_PD_SPEED_TYPE_E 统一枚举 */
static guint8 parse_mr_pd_speed(guint8 fw_speed)
{
    switch (fw_speed) {
        case 0x00: return PD_SPEED_UNDEFINED;   /* MR_PD_SPEED_UNKNOWN  */
        case 0x01: return PD_SPEED_1P5G;
        case 0x02: return PD_SPEED_3G;
        case 0x03: return PD_SPEED_6G;
        case 0x04: return PD_SPEED_12G;
        case 0x05: return PD_SPEED_22P5G;       /* 新固件扩展：SAS4 22.5G */
        case 0x80: return PD_SPEED_2P5G;        /* PCIe 2.5GT/s */
        case 0x81: return PD_SPEED_5G;          /* PCIe 5GT/s   */
        case 0x82: return PD_SPEED_8G;          /* PCIe 8GT/s   */
        case 0x83: return PD_SPEED_16G;         /* PCIe 16GT/s  */
        default:   return PD_SPEED_UNKNOWN;
    }
}

/* FillPDInfo 中 */
pPDinfo->pdinfo.device_speed = parse_mr_pd_speed(PdInfo->deviceSpeed);
pPDinfo->pdinfo.link_speed   = parse_mr_pd_speed(PdInfo->linkSpeed);

同时回退 Lua 侧补丁。这样所有消费方一次性修正

4

什么类型的盘的回显速率会到达22.5Gbps

5

带内和带外查询，硬盘的序列号和型号不一样，带内能提供同SN/型号的查询结果吗？

6

image
image1733×683 122 KB

这张图能够和OS内查询的序列号和型号和一致，可以看到协商速率是2.5Gbps

7

这个问题是必现的吗，还是概率性的？
（1）提供一下带内raid卡驱动/固件/工具的版本。
（2）带内通过storcli命令收集一下raid卡的日志。

8

1.这是必现的问题；

Log.zip (12.1 MB)

9

正式方案需要在内源的raid卡适配库sml中适配，可以联系pae提供lts的patch版本；或者等待下一个lts版本发布

10

有明确的下一个是什么版本会带上吗

11

openUBMC 26.09