| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: 流销毁后线程变量的流信息没有清除 Co-authored-by: sunnana_004434229<sunnana@huawei.com> # message auto-generated for no-merge-commit merge: !4700 merge fix/clear-thread-local-stream-after-destroy into master fix: 流销毁后线程变量的流信息没有清除 Created-by: sunnana_004434229 Commit-by: sunnana_004434229 Merged-by: cann-robot Description: # Pull Request ## 描述 本次 Pull Request 包含以下修改： 1. 流销毁后线程变量的流信息没有清除，导致线程局部变量可能持有失效的流指针。本次在流销毁时清除与该流匹配的线程局部资源限制流信息，并在 Runtime 进程退出清理阶段重置该线程局部变量。 2. 为 aclrtLaunchKernelWithHostArgsImpl 增加启动日志。 3. 扩展 DavidStarsModelMaintaince SQE，增加 notify ID 扩展标志和 32 位 endgraph notify ID，适配 A5/A6 上超过 64K 的 notify ID。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无。 ## 如何测试 描述测试此变更的步骤和前提条件： 1. 执行 python3 .claude/skills/runtime-llt-run/scripts/runtime_llt_select_and_run.py --committed-only。 2. 精准 LLT 构建 7 个测试目标并执行 114 个用例，结果为 0 失败、0 超时。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次 PR 共包含 2 个提交、5 个修改文件；接口签名未发生变化。 See merge request: cann/runtime!4700 | 1 天前 | |
fix:日志整改 Co-authored-by: liu-lu<www.liulu824910939@qq.com> # message auto-generated for no-merge-commit merge: !4722 merge master into master fix:日志整改 Created-by: liu-lu Commit-by: liu-lu Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 对 aicpu_sched / queue_schedule / tsd 模块进行日志质量整改，共涉及 15 个源文件与 4 个 UT 文件，不改变任何功能逻辑： 1. **术语修正**： src/queue_schedule/common/bqs_log.h 中整数溢出误写为 "Integer reversed"，修正为 "Integer overflow"（3 处），避免误导排查方向； 2. **语法/拼写修正**：exist → exists、dequed → dequeued、is not equal with → is not equal to、input param is error → input param is invalid、Success to alloc/init/free/uninit → Successfully alloced/inited/freed/uninited、paramHead → ParamHead 等； 3. **日志上下文增强**： - 补充场景标识：in ts kernel（hwts_kernel_model_control）、in datadump（datadump_interface）； - 补充参数详情：kernelName / resultAddr 是否为 null（hwts_kernel_model_process）、aicpuLogIndex 实际值与有效范围 [0, size)（qs_interface_process）、depth 有效范围 [1, MAX_QUEUE_DEPTH]（comm_channel_queue）； - 补充单位：时间 us（msprof_manager）、内存 bytes（simple_entity、comm_channel_queue）； 4. **日志语义区分**：RouterServer 解析报错区分 query msg / non-query msg；ManageQsEvent 失败区分 para error / other error； 5. **新增 UT 用例**（11 个）： - tests/ut/queue_schedule/ut/testcase/bqs_log_utest.cpp：BqsCheckAssign32UAdd / 32UMuti / 64UAdd 溢出与正常分支共 8 个用例； - tests/ut/queue_schedule/ut/testcase/qs_interface_utest.cpp：GetAicpuPhysIndex 越界用例（越界返回 0）； - tests/ut/queue_schedule/ut/testcase/queue_schedule_low_cov_utest.cpp：CommChannelQueue Init 非法 depth、Init+Uninit 共 2 个用例。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue Close #930 ## 如何测试 1. **编译构建测试**：全量编译 aicpu_sched / queue_schedule / tsd 及 tests 模块，确认无编译错误与新增告警； 2. **单元测试**：执行 queue_schedule 与 aicpu_sched 的 UT，确认新增用例全部通过： - BqsCheckAssign32UAdd/Muti/64UAdd*：溢出分支置 onceOverFlow=true 且结果为 0，正常分支计算结果正确； - GetAicpuPhysIndexOutOfRange001：aicpuLogIndex 越界时返回 0； - CommChannelQueueInitInvalidDepth / CommChannelQueueInitAndUninit：depth 为 0 或超过 MAX_QUEUE_DEPTH 时 Init 返回 FSM_FAILED； - 回归 operator_kernel_gather_dequeue_test 原有用例（拼写修正不影响行为）； 3. **日志输出验证**：构造整数溢出、参数非法、AICPU 索引越界等异常场景，确认日志输出修正后的术语（Integer overflow）及新增上下文信息（实际值、有效范围、单位）。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 源代码变更均为日志文本调整，不涉及控制流与数据流改动，无功能/性能风险； - 本 PR 不涉及文档变更（日志文案不属于文档范畴）； - 变更统计：19 个文件，新增约 133 行，删除约 38 行。 See merge request: cann/runtime!4722 | 1 天前 | |
【PR】: soc version rename Co-authored-by: zhongliang<zhongliang2@huawei.com> # message auto-generated for no-merge-commit merge: !4713 merge master into master 【PR】: soc version rename Created-by: zhongliangtx Commit-by: zhongliang Merged-by: cann-robot Description: # Pull Request ## 描述 请清晰准确地描述本次 Pull Request 的意图和变更内容。 Ascend960 soc version rename ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 测试Ascend960基础用例。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4713 | 23 小时前 | |
fix: msn hal label Co-authored-by: z_AUV<zhangchangwei6@h-partners.com> # message auto-generated for no-merge-commit merge: !4562 merge pr_msn_hal into master fix: msn hal label Created-by: z_AUV Commit-by: z_AUV Merged-by: cann-robot Description: # Pull Request ## 描述 请清晰准确地描述本次 Pull Request 的意图和变更内容。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [ ] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [ ] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4562 | 22 小时前 | |
fix: 优化 ERROR 日志枚举名称输出(#926) Co-authored-by: zhaowenrui666<zhaowenrui7@huawei.com> # message auto-generated for no-merge-commit merge: !4680 merge fix/enum-error-log-names into master fix: 优化 ERROR 日志枚举名称输出(#926) Created-by: zhaowenrui666 Commit-by: zhaowenrui666 Merged-by: cann-robot Description: # Pull Request ## 描述 部分 ERROR 日志仅输出枚举数值，定位问题时需要额外查询枚举定义，影响日志可读性和故障分析效率。本次统一优化相关日志：存在有效枚举名称时输出 枚举名称(原始值)，同时保留原始数值用于识别异常输入。 主要变更如下： 1. 为 AICPU Schedule、AICPU Sharder、Queue Schedule 和 TSD 涉及的枚举补充名称转换能力。 2. 新增类型安全的 EnumNameTable Traits 注册表和统一 GetEnumName 查询接口；14 个自定义枚举由 switch 转为按枚举类型注册的静态 map，后续新增枚举只需补充对应特化。 3. 枚举名称转换接口统一返回 std::string，日志调用处通过 c_str() 传递字符串，不引入裸字符指针接口；未注册的枚举值统一返回 UNKNOWN。 4. protobuf 枚举优先复用生成的名称转换接口，避免重复维护映射关系；BQS 消息类型保留 UNKNOWN(原始值) 兜底。 5. SOMA、Dump 和 HCCL Protocol 等明确非法且无法获得有效名称的场景仅输出原始数值，避免打印无意义的枚举名称。 6. 补充 AICPU Sharder 构建及 UT/ST 的公共头文件搜索路径。 7. 精简 DgwClient::CheckConfigNum() 的冗余作用域和末尾 break，并合并 BqsServer::HandleBqsReqMsg() 的相邻日志字符串，使两个函数的 NBNC 均降至 50，不改变控制流及日志内容。 8. PR 变更已整理为单个有效提交。 本次仅整改 ERROR 级别的枚举日志，不改变业务流程、返回值及错误处理逻辑，也不扩大到协议字段等非枚举数值。 ## 变更类型 - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 关联 Issue：https://gitcode.com/cann/runtime/issues/926 ## 如何测试 1. 对本次提交涉及的文件执行 pre-commit，检查通过。 2. tsd_client_utest、queue_schedule_main_ut、aicpu_sharder_utest 和 aicpu_aicpuschedule_utest 均编译通过。 3. 注册查表改造前新增失败用例，确认统一查询接口尚不存在；改造后该用例及未知值兜底检查通过。 4. 完整回归：AICPU Schedule 1480 个、AICPU Sharder 74 个、Queue Schedule 685 个、TSD 881 个用例均通过。 5. 使用 AICPU Sharder 的实际头文件和宏配置，以 C++11 标准对 aicpu_context.cc 执行语法编译检查，通过。 6. 移动仓内公共头后，生产目标 host_queue_schedule 的全部对象编译及可执行文件链接通过。 7. NBNC 调整后，DgwClient::CheckConfigNum() 和 BqsServer::HandleBqsReqMsg() 的 NBNC 均为 50。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档（本次变更不涉及用户文档，无需更新） - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本次变更范围限定为 AICPU Schedule、AICPU Sharder、Queue Schedule 和 TSD 中的 ERROR 级别枚举日志，不涉及业务流程、返回值和资源所有权变更。 See merge request: cann/runtime!4680 | 1 天前 | |
feat: update .pre-commit-config.yaml for mmpa & error_manager Co-authored-by: likun104<likun104@h-partners.com> # message auto-generated for no-merge-commit merge: !3771 merge br_update_pre-commit-config.yaml into master feat: update .pre-commit-config.yaml for mmpa & error_manager Created-by: likun104 Commit-by: likun104 Merged-by: cann-robot Description: # Pull Request ## 描述 为mmpa & error_manager更新“.pre-commit-config.yaml”文件中的配置 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 流水线跑通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!3771 | 1 个月前 | |
fix: log冗余头文件整改，消除软链与多副本 Co-authored-by: GuoWenbo<guowenbo13@h-partners.com> # message auto-generated for no-merge-commit merge: !4643 merge fix/issue831-log-header-normalization into master fix: log冗余头文件整改，消除软链与多副本 Created-by: GuoWenbo Commit-by: GuoWenbo Merged-by: cann-robot Description: ## 描述 按 issue #831 要求，消除 log 组件冗余头文件，按「对外开放程度 include > pkg_inc > src」归一。整改覆盖两层： - **源码树**： include/pkg_inc/src 三层下每个头文件只保留一份实体 - **发布包**：同名头文件只保留一份实体，其余为软链 本 PR 为单个提交。 ## 一、源码树整改 **保留 4 份实体**：include/dfx/base/{log_types.h,alog_pub.h}、pkg_inc/base/{dlog_pub.h,plog.h}。 | 文件 | 原性质 | 处理 | 与保留份的差异 | |---|---|---|---| | pkg_inc/base/log_types.h | 软链 → ../../include/dfx/base/log_types.h | 删除 | 无内容差异 | | src/dfx/log/inc/toolchain/log_types.h | 实体副本 3597B | **改为软链** → include/dfx/base/log_types.h | 多 DQS = 13（已合并入保留份）；无行尾换行 | | src/dfx/log/inc/toolchain/dlog_pub.h | 实体副本 8324B | **改为软链** → pkg_inc/base/dlog_pub.h | 少 4 行注释 | | src/dfx/log/inc/toolchain/alog_pub.h | 实体副本 1725B | 删除 | sha256 与保留份完全相同 | | src/dfx/log/inc/toolchain/plog.h | 实体副本 1967B | 删除 | 少 1 个空行 | 整改后 4 个头文件各仅 1 份实体，src 层重复内容归零。 trace 组件（pkg_inc/trace、pkg_inc/watchdog、src/dfx/trace/inc/toolchain）逐个排查无多副本，零改动。 ### 为什么 src 层保留两个软链 issue 的目标是消除**冗余副本**（同一头文件多份可独立漂移的实体）。软链不构成副本：它与保留份始终同一内容，无漂移风险。 保留这两个软链是**防御性**的，让 include path 上带 src/dfx/log/inc/toolchain 的消费方继续能按短名解析。 需要说明：**当前仓内没有任何代码依赖这两个软链**。全仓 #include "toolchain/log_types.h" 与 "toolchain/dlog_pub.h" 引用数均为 0；按短名引用的消费方，其 include path 也都不含 inc/toolchain（抽查 10 个，9 个无该路径，1 个仅有 inc）。所以它们是为树外联编与后续新增代码留的兼容层，不是为修复仓内某处引用。 alog_pub.h 与 plog.h 未保留软链：前者在 src 下无对应引用，后者原有 3 处 #include "toolchain/plog.h" 已改为短名。 ## 二、发布包整改 改 scripts/package/module/ascend/RuntimeInc.xml（一增一删两行），使发布包内同名头文件只有一份实体。 整改前 log_types.h 在发布包内是**两份独立实体**（include/base/ 与 pkg_inc/base/ 各一份，内容相同但互不关联），因为两条 install 规则都指向源码树同一文件。整改后归一为「include/base 一份实体 + 其余软链指向它」： | 发布包路径 | 整改前 | 整改后 | |---|---|---| | include/base/log_types.h | 实体 | **实体（唯一实体）** | | pkg_inc/base/log_types.h | 实体 | **软链 → ../../include/base/log_types.h** | | include/toolchain/log_types.h | 软链 → ../../pkg_inc/base/log_types.h | 软链 → **../base/log_types.h** | 发布包 log 相关文件由 **8 实体 + 2 软链** 变为 **7 实体 + 3 软链**，总数仍为 10，无增无减。 include/toolchain/log_types.h 的指向变更是连带的：它原先指向 pkg_inc/base 那份，而那份现已改为软链，故改为直接指向实体，避免软链套软链。对下游无影响（路径不变、读到内容不变）。 实现方式沿用仓内既有先例：package.cmake 在 CPack staging 放实体，XML 的 install_softlink 再把列为软链目标的替换为软链，相对路径由打包框架自动计算。prof_api.h 即此模式（package.cmake 装 2 份，XML 转 1 份为软链，最终 1 实体 3 软链）。package.cmake 本次无需改动。 其余 6 个头文件（alog_pub.h、acl_log.h、err_msg.h、dlog_pub.h、err_mgr.h、plog.h）在发布包内本就各仅 1 份实体，零改动。 ## 编译依赖适配 **主路径**：slog_headers **新增** include/dfx/base（src/dfx/log/liblog/slog/CMakeLists.txt）—— 一处覆盖 153 个 link 该 target 的消费者，target_link_libraries 会传播 INTERFACE include 路径。 原有 4 条路径（${TOOLAHCIN_LOG_DIR}/inc、inc/toolchain、.../pkg_inc、.../pkg_inc/base）**全部保留**。本 PR 对 slog_headers 是纯新增、不删任何路径，消费方现有依赖不受影响，**外部组件无需任何适配**（新路径集合是原 4 条的超集）。 **硬路径**：25 个 cmake 文件用 include_directories() 硬写路径、拿不到 INTERFACE 传播，逐个补齐（tests/ut 11 个、tests/depends 7 个、src 7 个）。其中 src/acl/aclrt_impl 是为下述短名改动新增。 **引用形式收敛**：4 处前缀引用改为短名，与仓内主流写法（plog.h 10 处、log_types.h 7 处、dlog_pub.h 23 处均为短名）一致： - src/acl/aclrt_impl/acl.cpp："toolchain/plog.h" → "plog.h"（该 target 不 link slog_headers，同时补 pkg_inc/base 路径；已验证不补则 fatal error: plog.h: No such file or directory） - tests/ut/runtime/runtime/stub/log_stub.cc："toolchain/plog.h" → "plog.h"（零 cmake 改动） - src/dfx/msprof/.../devprof_drv_aicpu.cpp："base/log_types.h" → "log_types.h"（零 cmake 改动） - src/tprt/feature/inc/tprt_base.hpp：**保持** "base/plog.h" 前缀形式 tprt_base.hpp 保留前缀形式是刻意的：它是头文件，改短名会把「须有 pkg_inc/base 在路径上」的要求传导给所有包含它的下游，而前缀形式只要求有 pkg_inc，约束宽得多。仓内 pkg_inc/base/err_mgr.h 同样用 #include "base/err_msg.h"，是同一考虑。 **其他**：cmake/package.cmake 删除已失效的 install 段（其引用的源文件已删除，不删会导致 install 阶段失败）；3 个 cmake 文件补齐缺失的 license header（src/platform、tests/ut/platform、tests/ut/aicpu_sched/aicpu_kernel/ut，本 PR 改动这些文件触发 OAT 检查，原文件即无 header）。 ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） ## 关联的Issue https://gitcode.com/cann/runtime/issues/831 ## 如何测试 1. 构建：bash build.sh --pkg --pkg-type=run -j16 —— 应输出 build success!，0 error 2. 装包并核对发布包结构： bash bash build_out/cann-npu-runtime_9.2.0_linux-aarch64.run --devel --quiet --install-path=<PATH> N=<PATH>/cann/aarch64-linux ls -la $N/include/base/ $N/pkg_inc/base/ $N/include/toolchain/ # 预期：include/base/log_types.h 为唯一实体， # pkg_inc/base/log_types.h 与 include/toolchain/log_types.h 为软链 3. 同名实体唯一性与软链有效性： bash for d in include/base pkg_inc/base include/toolchain; do for f in $N/$d/*; do [ -L "$f" ] || basename "$f"; done done | sort | uniq -c | awk '$1>1{print "重复实体:",$2}' # 应无输出 find $N/include/base $N/pkg_inc/base $N/include/toolchain -type l \ -exec test -e {} \; -print | wc -l # 应为 3（全部有效） grep -nE "HIXL|DQS|DEVMM" $N/include/base/log_types.h # DQS=13 应在 12 与 22 之间 4. 源码树软链： bash readlink -e src/dfx/log/inc/toolchain/{log_types.h,dlog_pub.h} # 应指向保留实体 git ls-tree HEAD src/dfx/log/inc/toolchain/ # 应为 mode 120000 ## 验证结论 **已完成全量构建与装包实测**（含发布包结构归一） | 项 | 结果 | |---|---| | 完整构建 | bash build.sh --pkg --pkg-type=run -j16 → build success!，0 个 error: | | 装包 | cann-npu-runtime_9.2.0_linux-aarch64.run（37MB）以 --devel 装至独立路径成功 | | 发布包同名实体唯一性 | **无任何文件名对应 >1 个实体**（按 basename 统计逐一确认） | | 发布包实体/软链构成 | **7 实体 + 3 软链 = 10**（整改前 8 实体 + 2 软链 = 10），总数无增无减 | | 3 条软链有效性 | 全部有效不悬空：pkg_inc/base/log_types.h → ../../include/base/log_types.h、include/toolchain/log_types.h → ../base/log_types.h、include/toolchain/slog.h → ../../pkg_inc/base/dlog_pub.h | | 经软链读取一致性 | 3 条 log_types.h 路径读到内容 sha256 全同（cf883df89a3a） | | 发布包内容差异 | 相对整改前**仅 log_types.h 一处**：3567B → 3598B，diff 输出仅 > DQS = 13, 一行 | | 其余 6 个头文件 | sha256 与整改前**完全相同**（alog_pub.h 3771757b5e、dlog_pub.h ab887476d1、plog.h c8e1f91404、err_mgr.h e09c8237ea、err_msg.h 5ded505fa2、acl_log.h 660c8a844f） | | 源码树软链未外泄 | 发布包内搜 *log/inc/toolchain* 无结果；内部头 slog_api.h 未被打包 | | 源码树软链有效性 | 2 条 readlink -e 均解析到保留实体；git 记为 mode 120000 | | 短名解析 | 3 处改动均验证可解析；acl.cpp 做了反向对照（不补路径则编译失败） | | trace 回归 | trace 侧零改动 | **对照基线说明**：整改前发布包数据取自本仓构建产物 staging，其 10 个文件 sha256 与 HEAD~1 的 git 对象逐项吻合，可作为可信 before 基线。发布包结构归一前后的对比，取自同一台环境两次独立装包（--install-path 指向不同目录）。 **预处理等价性验证**（源码树改动部分） | 项 | 结果 | |---|---| | 预处理逐字节比对 | 整改前后均 8888 行，sha256 均 7209fcfc54ca，diff 无输出 | 做法：git stash 将工作区退回同一基线，用相同 include path 对真实源文件（plog_device_log.c）预处理一次，恢复改动后再预处理一次，两份输出 sha256 完全相同 —— 证明删副本、调 include path 对编译器最终看到的 token 流零影响。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 ### 对外接口变更（需兼容性评审） **新增一个对外可见枚举 DQS = 13** 该值原仅存在于源码树 src/dfx/log/inc/toolchain/log_types.h。整改前发布包两处 log_types.h 均取自 include/dfx/base 版而**不含 DQS**（已装包实测确认：整改前 3567B / f1a36a756418，正是 include/dfx/base 版的 sha），故该值此前从未真正对外，本次归并是首次外露。 保留它是为避免删除 src 副本时丢失定义。实测确认它填补 HIXL = 12 与 DEVMM = 22 之间空位（新包中位于第 58 行，前后分别为 57 行 HIXL = 12 与 59 行 DEVMM = 22），**不改变任何既有枚举值**。 ### 发布包结构变更对下游的影响 pkg_inc/base/log_types.h 由实体变为软链，include/toolchain/log_types.h 软链指向由 ../../pkg_inc/base/log_types.h 改为 ../base/log_types.h。 **对正常使用无影响**：三条路径均存在、均可读、内容一致（实测 sha256 相同）。#include 行为不变。 可能受影响的场景：以 -type f 精确匹配实体文件的打包/校验脚本，或强校验软链目标字符串的工具。若下游有此类校验，需同步更新预期值。 ### 删除 install(FILES) 段是否导致发布包文件变少 **不会。已装包实测确认发布包 include/base/ 下 4 个文件一个不少，清单与整改前逐项一致。** 被删的那段与 package.cmake:116 的 install(DIRECTORY ${RUNTIME_DIR}/include/dfx/base/) 目标目录完全相同，且该目录已包含被删段要装的两个文件（alog_pub.h、log_types.h），故被删段是**完全冗余的重复安装**。 实测证据：整改前发布包 include/base/log_types.h 为 3567B / f1a36a756418，等于整改前 include/dfx/base/log_types.h 的 sha，而**不等于**被删段的源 src/dfx/log/inc/toolchain/log_types.h（3597B / bc708128af41）—— 说明 install(DIRECTORY) 执行在后并覆盖了 install(FILES)，被删段本就是死代码。alog_pub.h 两个源 sha 完全相同，谁覆盖谁一致。 删除它的必要性：它引用的源文件已随本次整改删除，不删会导致 install 阶段失败。 ### include/toolchain/slog.h 是历史兼容别名 发布包 include/toolchain/slog.h 指向 pkg_inc/base/dlog_pub.h（实测两者 sha 相同），并非源码树中真正的 slog.h。该别名同由 RuntimeInc.xml 的 install_softlink 生成，**本次未改动该条目**，别名语义与指向均不变（其目标 dlog_pub.h 仍是实体）。源码树中真正的 slog.h（内部头）与 slog_api.h 均不打包，已实测确认。 ### git diff --check 说明 git diff --check 会报 trailing whitespace。已用最小工程复现确认：**纯 CRLF 文件新增任何一行都会被报，与内容无关**（git 把 \r 视作行尾空白）。报警文件中多数为纯 CRLF，混合行尾文件的 LF 行数与基线完全一致（未引入行尾变更）。本 PR 未引入真实的尾随空白。 ### 未闭环边界 UT 侧未覆盖验证。tests/ut/platform 的 platform_llt 编译产品源文件 src/platform/acl_platform.cpp 但未提供 securec 路径，tests/build_ut.sh -u 在该处即 fatal error: securec.h，阻塞在 UT 链最前端。该问题在整改前的基线上同样存在（已用 git checkout HEAD~1 确认同一处同一错误），非本 PR 引入。 See merge request: cann/runtime!4643 | 4 天前 | |
fix:日志整改 Co-authored-by: liu-lu<www.liulu824910939@qq.com> # message auto-generated for no-merge-commit merge: !4722 merge master into master fix:日志整改 Created-by: liu-lu Commit-by: liu-lu Merged-by: cann-robot Description: # Pull Request ## 描述 本 PR 对 aicpu_sched / queue_schedule / tsd 模块进行日志质量整改，共涉及 15 个源文件与 4 个 UT 文件，不改变任何功能逻辑： 1. **术语修正**： src/queue_schedule/common/bqs_log.h 中整数溢出误写为 "Integer reversed"，修正为 "Integer overflow"（3 处），避免误导排查方向； 2. **语法/拼写修正**：exist → exists、dequed → dequeued、is not equal with → is not equal to、input param is error → input param is invalid、Success to alloc/init/free/uninit → Successfully alloced/inited/freed/uninited、paramHead → ParamHead 等； 3. **日志上下文增强**： - 补充场景标识：in ts kernel（hwts_kernel_model_control）、in datadump（datadump_interface）； - 补充参数详情：kernelName / resultAddr 是否为 null（hwts_kernel_model_process）、aicpuLogIndex 实际值与有效范围 [0, size)（qs_interface_process）、depth 有效范围 [1, MAX_QUEUE_DEPTH]（comm_channel_queue）； - 补充单位：时间 us（msprof_manager）、内存 bytes（simple_entity、comm_channel_queue）； 4. **日志语义区分**：RouterServer 解析报错区分 query msg / non-query msg；ManageQsEvent 失败区分 para error / other error； 5. **新增 UT 用例**（11 个）： - tests/ut/queue_schedule/ut/testcase/bqs_log_utest.cpp：BqsCheckAssign32UAdd / 32UMuti / 64UAdd 溢出与正常分支共 8 个用例； - tests/ut/queue_schedule/ut/testcase/qs_interface_utest.cpp：GetAicpuPhysIndex 越界用例（越界返回 0）； - tests/ut/queue_schedule/ut/testcase/queue_schedule_low_cov_utest.cpp：CommChannelQueue Init 非法 depth、Init+Uninit 共 2 个用例。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue Close #930 ## 如何测试 1. **编译构建测试**：全量编译 aicpu_sched / queue_schedule / tsd 及 tests 模块，确认无编译错误与新增告警； 2. **单元测试**：执行 queue_schedule 与 aicpu_sched 的 UT，确认新增用例全部通过： - BqsCheckAssign32UAdd/Muti/64UAdd*：溢出分支置 onceOverFlow=true 且结果为 0，正常分支计算结果正确； - GetAicpuPhysIndexOutOfRange001：aicpuLogIndex 越界时返回 0； - CommChannelQueueInitInvalidDepth / CommChannelQueueInitAndUninit：depth 为 0 或超过 MAX_QUEUE_DEPTH 时 Init 返回 FSM_FAILED； - 回归 operator_kernel_gather_dequeue_test 原有用例（拼写修正不影响行为）； 3. **日志输出验证**：构造整数溢出、参数非法、AICPU 索引越界等异常场景，确认日志输出修正后的术语（Integer overflow）及新增上下文信息（实际值、有效范围、单位）。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 源代码变更均为日志文本调整，不涉及控制流与数据流改动，无功能/性能风险； - 本 PR 不涉及文档变更（日志文案不属于文档范畴）； - 变更统计：19 个文件，新增约 133 行，删除约 38 行。 See merge request: cann/runtime!4722 | 1 天前 | |
【PR】: fix: 统一 Event 和 Notify 接口参数名（#889） Co-authored-by: ningjingyuan<ningjingyuan@huawei.com> # message auto-generated for no-merge-commit merge: !4622 merge fix/api-param-event-notify into master 【PR】: fix: 统一 Event 和 Notify 接口参数名（#889） Created-by: ningjingyuan Commit-by: ningjingyuan Merged-by: cann-robot Description: # Pull Request ## 描述 NULL_PTR_RETURN_MSG_OUTER_WITH_FUNC_DESC 会通过 #PTR 将参数名写入错误信息。当 ApiImpl、装饰器或错误检查层的参数名与 rt 接口不一致时，最终展示的参数名会偏离接口文档。 本 PR 统一 Notify*、CntNotify* 等 Event 和 Notify 接口的参数名，并同步虚接口、C 接口、装饰器、错误检查层、各平台实现及 stub。同时修复 rtGetNotifyAddress 输出形参 notifyAddres 少一个 s 的拼写错误，统一为 notifyAddress。不改变参数类型、顺序和运行行为。 ## 变更类型 <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 关联：https://gitcode.com/cann/runtime/issues/889 本 PR 是 Issue 889 的拆分子项，请关联该 Issue，但不要单独勾选“合并后关闭已关联的 Issue”；待五个子 PR 全部合入后再关闭。 ## 如何测试 前提条件：已安装项目依赖并完成 build/ 目录配置。 1. 对本 PR 修改文件执行 pre-commit run clang-format --files <本 PR 变更文件>。 2. 完成 runtime_v100、runtime_v200 和 runtime_v201 目标构建。 3. 运行 runtime_utest_xpu，共 168 个用例通过。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 本次变更不涉及文档内容更新 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 本 PR 从 Issue 889 的整体参数名整改中独立拆分，只包含 Event、Notify 和 CountNotify 相关改动。 See merge request: cann/runtime!4622 | 21 小时前 | |
feat:nano支持rtsPointerGetAttributes接口 Co-authored-by: maxiaofan2<maxiaofan2025@163.com> # message auto-generated for no-merge-commit merge: !4371 merge rts-pointer-attributes-20260820 into master feat:nano支持rtsPointerGetAttributes接口 Created-by: maxiaofan2 Commit-by: maxiaofan2 Merged-by: cann-robot Description: # Pull Request ## 描述 在 Runtime Compact 中新增 rtsPointerGetAttributes 接口，通过 HAL 查询指针的 Host/Device 内存属性，并补充参数校验及 Linux、LiteOS 单元测试。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 2. ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [ ] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [ ] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4371 | 5 天前 | |
【PR】: 删除临时桩 libxpu_tprt.so Co-authored-by: guo-yanjun<guoyanjun3@huawei.com> # message auto-generated for no-merge-commit merge: !4705 merge xpu_tprt_0905 into master 【PR】: 删除临时桩 libxpu_tprt.so Created-by: guo-yanjun Commit-by: guo-yanjun Merged-by: cann-robot Description: # Pull Request ## 描述 xpu_tprt 已完成静态内部化，真实实现通过 libxpu_tprt.a 链接到libruntime_v100.so 和 libruntime_v200.so。libxpu_tprt.so 相应的打包配置已被清理，过渡阶段使用的同名空桩 SO 已无保留必要。 本 PR 完成最后阶段的桩 SO 清理： 1. 删除 src/tprt/stub/xpu_tprt_compat_stub.c 桩源码。 2. 删除 xpu_tprt_compat_stub 共享库 target 及其属性配置。 3. 删除 add_dependencies(xpu_tprt xpu_tprt_compat_stub) 构建依赖。 4. 删除 src/tprt/CMakeLists.txt 和 cmake/package.cmake 中的桩 SO 安装规则。 5. 删除 RuntimeSo.xml 中 libxpu_tprt.so 的打包条目。 清理后： - 构建过程只生成内部静态库 libxpu_tprt.a，不再生成桩 libxpu_tprt.so。 - libxpu_tprt.a 继续通过 --whole-archive 链接到 Runtime。 - 安装目录和交付包不再发布 libxpu_tprt.so 或 libxpu_tprt.a。 - Runtime 不依赖 libxpu_tprt.so，TPRT 接口也不会通过动态符号表对外暴露。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue https://gitcode.com/cann/runtime/issues/821 https://gitcode.com/cann/runtime/issues/822 https://gitcode.com/cann/runtime/issues/823 ## 如何测试 1. 构建 runtime_v100 和 runtime_v200，验证编译链接成功。 2. 检查构建产物，确认仅生成 libxpu_tprt.a，不再生成 libxpu_tprt.so。 3. 使用 readelf 和 nm 确认 Runtime 不依赖 libxpu_tprt.so，且未动态导出 TPRT 符号。 4. 检查安装包，确认不再包含 libxpu_tprt.so 和 libxpu_tprt.a。 5. 执行外部可达性和功能回归验证。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [ ] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4705 | 1 天前 | |
fix: 修复包互斥文件探测的资源泄漏和路径错误 Co-authored-by: zhaowenrui666<zhaowenrui7@huawei.com> # message auto-generated for no-merge-commit merge: !4724 merge fix/package-env-info-mutex-access into master fix: 修复包互斥文件探测的资源泄漏和路径错误 Created-by: zhaowenrui666 Commit-by: zhaowenrui666 Merged-by: cann-robot Description: # Pull Request ## 描述 PackageEnvInfo::GetCurHostMutexFile 原先通过 open() 判断 libqueue_schedule.so 是否存在，探测成功后会遗留文件描述符，并可能将完整路径作为文件名返回，导致调用方重复拼接 host so 路径。 本次改为使用仓库跨平台封装 mmAccess() 检查文件是否存在，不再创建文件描述符，同时保持接口返回文件名的既有约定。新增 queue so 存在和不存在场景的单元测试。 ## 变更类型 <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 关联并修复 #928：https://gitcode.com/cann/runtime/issues/928 ## 如何测试 描述测试此变更的步骤和前提条件： 1. 执行 cmake --build build --target tsd_client_utest -j4，确认目标编译成功。 2. 执行 build/tests/ut/tsd/tsdclient/tsd_client_utest，888 个用例全部通过。 3. 执行 pre-commit run，clang-format 和 OAT 检查通过。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 本次变更不涉及文档更新 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 无。 See merge request: cann/runtime!4724 | 22 小时前 | |
fix: runtime_platform_arch5162缺少对c_sec的依赖声明 Co-authored-by: lianglongzi8622<lianglongzi@huawei.com> # message auto-generated for no-merge-commit merge: !3623 merge fix/arch5162-csec-dependency into master fix: runtime_platform_arch5162缺少对c_sec的依赖声明 Created-by: lianglongzi8622 Commit-by: lianglongzi8622 Merged-by: cann-robot Description: # Pull Request ## 描述 runtime_platform_arch5162缺少对c_sec的依赖声明，导致并行构建时csec_src可能尚未下载解压securec.h就开始编译dev_info_reg.cc，首次构建失败，第二次因stamp已存在而成功。 ## 变更类型 - [x] 🐛 Bug 修复 ## 修复内容 在src/CMakeLists.txt守护块中补上： cmake add_dependencies(runtime_platform_arch5162 c_sec) ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我在标题中使用了合适的类型标签 See merge request: cann/runtime!3623 | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 天前 | ||
| 1 天前 | ||
| 23 小时前 | ||
| 22 小时前 | ||
| 1 天前 | ||
| 1 个月前 | ||
| 4 天前 | ||
| 1 天前 | ||
| 21 小时前 | ||
| 5 天前 | ||
| 1 天前 | ||
| 22 小时前 | ||
| 1 个月前 |