伙伴当前已经在main分支完成开发,并且测试报告通过了QA-SIG评审,计划将代码反合LTS分支。
但是目前LTS分支仍存在此问题适配佰维 SATA SSD,搭配SP686C-M-16i时,厂商信息显示ATA。
已知需要合入如下修改和打开sml_open出包才能正常显示厂商信息。
讨论点:
1、LTS分支上是否可以合入相关修改解决此问题
伙伴当前已经在main分支完成开发,并且测试报告通过了QA-SIG评审,计划将代码反合LTS分支。
但是目前LTS分支仍存在此问题适配佰维 SATA SSD,搭配SP686C-M-16i时,厂商信息显示ATA。
已知需要合入如下修改和打开sml_open出包才能正常显示厂商信息。
讨论点:
1、LTS分支上是否可以合入相关修改解决此问题
答案内容由AI生成,仅供参考:
根据上下文,此问题的已知解决方案包含以下两点:
his_trans_drive_data 的接口名称从 histore_trans_drive_data 修改为 his_trans_drive_data。sml_open 组件出包:需要确保在构建 LTS 分支的固件时,sml_open 组件被包含在发布的软件包中。结论:是的,可以在 LTS 分支上合入相关修改来解决此问题。
伙伴提出的方案是可行且正确的。LTS 分支完全可以合入此代码修改并开启 sml_open 组件,以解决佰维 SATA SSD 搭配 SP686C-M-16i 时厂商信息显示为 ATA 的问题。此修复风险可控,且已在 main 分支上得到验证。
好的,根据您提供的上下文信息和问题描述,以下是对该问题的分析及解决方案讨论。
伙伴在 LTS 分支 上适配 佰维 SATA SSD,并搭配 SP686C-M-16i 或 1880 RAID 卡 时,厂商信息错误地显示为 ATA。该问题在 main 分支上已修复并通过测试,计划将此修复反合到 LTS 分支。
根据上下文,此问题的已知解决方案包含以下两点:
his_trans_drive_data 的接口名称从 histore_trans_drive_data 修改为 his_trans_drive_data。sml_open 组件出包:需要确保在构建 LTS 分支的固件时,sml_open 组件被包含在发布的软件包中。讨论点:LTS分支上是否可以合入相关修改解决此问题
结论:是的,可以在 LTS 分支上合入相关修改来解决此问题。
问题的根因已明确:
sml_pd trans drive data: trans drive data failed ret[0x10c2],其中 0x10c2 对应于 SML_ERR_NULL_INTERFACE。SP686C-M-16i 是一个功能正常的RAID卡型号,问题在于软件层面的接口调用。修复方案已验证且有效:
main 分支的修复通过将函数名对齐,解决了接口不匹配的问题。这在逻辑上是低风险的修改,可以直接移植到 LTS 分支。sml_open 组件出包,确保了修复后的代码能够被正确编译和链接到最终的固件中。LTS 分支的具体操作步骤:
main 分支上关于“头文件变更同步”的 PR(即修改函数名为 his_trans_drive_data 的提交)cherry-pick 或手动合入到 LTS 分支。Makefile、CMakeLists.txt 或类似文件),确保 sml_open 软件包被列为构建和打包项。HIKSEMI, INNOGRIT 或 LONGSYS)。storage 和 libprotocol 等组件的版本与 main 分支的修复没有冲突。从上下文看,此修改主要影响 storage 组件,冲突风险较低。9560-8i、9560-16i 等模型。伙伴提出的方案是可行且正确的。LTS 分支完全可以合入此代码修改并开启 sml_open 组件,以解决佰维 SATA SSD 搭配 SP686C-M-16i 时厂商信息显示为 ATA 的问题。此修复风险可控,且已在 main 分支上得到验证。
刚刚分析了代码只能通过使用社区的sml_open来解决
感谢,昨天会上说这个改动影响可能还挺大的,适合伙伴来改不![]()
只是切换编译和使用,风险可控,充分验证保证质量,且有其他伙伴也进行了切换
@changxingOpenUBMC @yelmh_kno07 德兴哥,明浩哥,修改PR已提起,还请帮忙检视合入,感谢https://gitcode.com/openUBMC/storage/pull/462