Pull Request已成功合入, 合并人@CANN-robot
(感谢 vaceciliachen 的贡献)变更摘要
本 PR 主要实现了 notify 事件获取和设备基准时间同步两个核心功能。在驱动层新增 halGetNotifyEvent 接口,并将其与 halGetFaultEvent 合并到统一的 GetEventsWithTimeCheck 流程中,通过 INFO_TYPE_REAL_TIME 获取设备实时时间作为基准时间(baseTime_),用于过滤历史事件。同时,将多处手动内存管理的 rtDmsFaultEvent 数组替换为 std::vector,重构了 MTE 错误处理逻辑,并统一调整了事件获取接口的签名。
主要改动
-
新增
halGetNotifyEvent驱动接口与INFO_TYPE_REAL_TIME设备信息类型:在ascend_hal_base.h中新增halGetNotifyEventAPI 声明和INFO_TYPE_REAL_TIME枚举值;在npu_driver_base.hpp中声明对应的弱符号,npu_driver_res.cc中实现GetNotifyEvents内部函数,将 notify 事件与 fault 事件合并到GetEventsWithTimeCheck统一获取,支持最多RAS_GET_MAX_NUM=256 个事件。 -
引入设备基准时间机制过滤历史事件:在
device.hpp中新增GetBaseTime()/SetBaseTime()虚方法,raw_device.cc中通过INFO_TYPE_REAL_TIME获取设备实时时间并存入baseTime_;在RawDevice::Init()、ApiImpl::MemUceRepair()和ApiImpl::RepairError()中调用SetBaseTime()同步基准时间;GetEventsWithTimeCheck中利用该时间过滤alarmRaisedTime早于基准时间的历史事件。 -
重构
GetAllFaultEvent接口与事件获取流程:NpuDriver::GetAllFaultEvent签名从(deviceId, dmsEvent, len, eventCount)改为(deviceId, dmsEvent, eventCount, needLog),内部优先检查halGetNotifyEvent符号是否存在,存在则走GetEventsWithTimeCheck合并路径;GetDeviceFaultEvents同步去掉maxFaultNum参数,新增needLog参数。 -
MTE 错误处理逻辑重写与
EventBlkEntry结构体引入:在device_error_info.hpp中新增EventBlkEntry结构体;GetMteDeviceFaultEvent函数从多 bool 输出参数改为遍历eventId2BlkList数组匹配事件,新增HBM_ECC_NOTIFY_EVENT_ID检查;SetTaskMteErrByType去除suppHbmRas判断,直接用HasMteErr()(对应 HBM ECC Notify)判断,远端错误码从TS_ERROR_SDMA_LINK_ERROR改为TS_ERROR_REMOTE_MEM_ERROR。 -
事件缓冲区管理从手动分配改为
std::vector并扩展容量:在device_error_core_proc.cc、v200_base/device_error_proc_c.cc、runtime.cc、api_impl.cc等多处,将原有的new/delete rtDmsFaultEvent[128]替换为std::vector<rtDmsFaultEvent>(RAS_GET_MAX_NUM),利用 RAII 自动管理内存,同时事件容量从 128 扩展到 256(含 fault 128 + notify 128),并在ProcUBMemNetworkException中新增lastReportTime去重逻辑。


代码审查
审查总结
我逐一审查了所有 22 个变更文件。以下是按优先级分组的发现汇总:
发现统计
- P2: 2 个
- P3: 1 个
- P0/P1: 0 个
各文件审查结果
| 文件 | 结果 |
|---|---|
include/driver/ascend_hal_base.h |
无问题 — 新增枚举值和函数声明正确 |
src/runtime/core/inc/device/device_error_info.hpp |
无问题 — EventBlkEntry 结构体设计合理,引用指向全局静态 map |
src/runtime/core/inc/device/device_error_proc.hpp |
无问题 — GetDeviceFaultEvents 签名变更已同步所有调用方 |
src/runtime/core/inc/runtime.hpp |
无问题 — 新增常量 RAS_GET_MAX_NUM_SI/RAS_GET_MAX_NUM,ProcUBMemNetworkException 去 const 合理 |
src/runtime/core/src/api_impl/api_impl.cc |
无问题 — GetAllFaultEvent 调用已更新,SetBaseTime 调用位置正确 |
src/runtime/core/src/api_impl/api_impl_david.cc |
无问题 — SetBaseTime 调用添加正确 |
src/runtime/core/src/device/device.hpp |
无问题 — 新增纯虚函数 GetBaseTime/SetBaseTime |
src/runtime/core/src/device/device_error_core_proc.cc |
无问题 — 用 vector 替代 raw new/delete,log 级别改为 ERROR 是有意为之 |
src/runtime/core/src/device/raw_device.cc |
无问题 — SetBaseTime 实现正确,错误处理合理 |
src/runtime/core/src/device/raw_device.hpp |
无问题 — baseTime_ 使用 std::atomic<int64_t>,线程安全 |
src/runtime/core/src/device/v200_base/device_error_proc_c.cc |
无问题 — GetMteDeviceFaultEvent 重构为表驱动,逻辑更清晰 |
src/runtime/core/src/runtime.cc |
P3 — faultEventInfo 跨设备迭代复用但未清零(防御性建议) |
src/runtime/core/src/task/task_info/model/model_execute_task.cc |
无问题 — 新增 TS_ERROR_LOCAL_MEM_ERROR/TS_ERROR_REMOTE_MEM_ERROR 到 MEM_ERROR_CODE 集合 |
src/runtime/driver/npu_driver.cc |
无问题 — INFO_TYPE_REAL_TIME 特殊处理正确 |
src/runtime/driver/npu_driver.hpp |
无问题 — GetAllFaultEvent 签名变更已同步 |
src/runtime/driver/npu_driver_base.hpp |
无问题 — halGetNotifyEvent weak symbol 声明正确 |
src/runtime/driver/npu_driver_res.cc |
P2 — 缺少 notifyEvtCnt 越界检查;P2 — GetFaultEvents 失败时 GetNotifyEvents 被跳过 |
src/runtime/driver/npu_driver_win.cc |
无问题 — Windows stub 已更新签名 |
src/runtime/feature/ccu/ccu_device_error_proc.cc |
无问题 — 格式说明符 %u→%hu 修正正确 |
tests/ut/runtime/runtime/test/platform/950/rt_utest_david.cc |
无问题 — stub 函数签名已更新,测试断言变更与逻辑变更一致 |
tests/ut/runtime/runtime/test/platform/950/rt_utest_david_task.cc |
无问题 — 测试间 SetDeviceRas(false) 复位正确 |
tests/ut/runtime/runtime/test/platform/950/stub/hal_stub.cc |
无问题 — halGetNotifyEvent stub 实现正确 |
整体风险评估
中等风险。核心功能变更(获取 notify 事件 + 设备时间同步)逻辑基本正确,但 npu_driver_res.cc 中 GetEventsWithTimeCheck 存在两个防御性缺口:缺少 notifyEvtCnt 越界检查,以及 GetFaultEvents 失败时未回退尝试 GetNotifyEvents。这两个问题在正常驱动行为下不会触发,但在边界场景(驱动异常、新平台 HAL 实现差异)下可能导致事件丢失或缓冲区越界。建议在合入前修复这两个 P2 问题。
| 类型 | 数量 |
|---|---|
| 🔴 阻塞 | 0 |
| 🟡 建议 | 2 |
💬 仅评论


/approve
/lgtm


/approve


Pull Request
描述
变更类型
请选择本次引入的变更类型:
关联的Issue
如何测试
描述测试此变更的步骤和前提条件:
1.
2.
核对清单
其他信息
在此添加任何其他关于本次 PR 的说明。