前言

在 CANN（Compute Architecture for Neural Networks）软件栈中，driver 仓库承担着连接上层运行时与底层硬件设备的关键桥梁作用。其核心职责包括设备管理、资源调度、通信通道维护以及异常处理等。随着 AI 模型规模的指数级增长和推理/训练任务对系统可靠性的严苛要求，driver 的稳定性已成为整个 CANN 生态能否高效、持续运行的基石。

一、Driver 架构概览与稳定性挑战

CANN driver 采用分层架构设计，主要包括 DCMI 层（DaVinci Card Management Interface）、HAL 层（Hardware Abstraction Layer）和 SDK-driver 层。这种设计实现了硬件细节的封装与上层接口的统一，但也带来了复杂的交互链路。

这些挑战直接催生了三大稳定性机制的需求：

• 超时检测：防止因硬件无响应或死锁导致整个系统挂起。
• 错误恢复：在发生可恢复错误后，能自动重置状态并继续服务。
• 日志追踪：提供全链路、细粒度的日志，以便快速定位问题根因。

---

二、超时检测机制：守护系统响应的生命线

超时检测是防止系统“假死”的第一道防线。CANN driver 在多个关键路径上部署了精细化的超时策略。

2.1 基于 wait_event_timeout 的内核级等待

在 HAL 层与内核驱动交互时，大量操作（如任务提交、内存分配）需要等待硬件中断或事件完成。driver 使用 Linux 内核提供的 wait_event_timeout 机制来安全地等待，并设置合理的超时阈值。

以 src/ascend_hal/hdc/host_device_comm.c 中的任务提交为例：

// src/ascend_hal/hdc/host_device_comm.c
int hdc_submit_task(struct hdc_context *ctx, struct task_desc *desc)
{
    DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wait);
    unsigned long timeout_jiffies;
    int ret;

    // ... (准备任务描述符)

    // 将任务提交到硬件队列
    ret = submit_to_hw_queue(ctx, desc);
    if (ret)
        return ret;

    // 设置超时时间为 5 秒 (CONFIG_HDC_TASK_TIMEOUT_S)
    timeout_jiffies = msecs_to_jiffies(CONFIG_HDC_TASK_TIMEOUT_MS);

    // 等待硬件完成中断
    ret = wait_event_timeout(
        ctx->task_wait_queue,
        atomic_read(&ctx->task_done_flag),
        timeout_jiffies
    );

    if (!ret) {
        // 超时处理
        dev_err(ctx->dev, "Task submission timed out after %d ms\n",
                CONFIG_HDC_TASK_TIMEOUT_MS);
        hdc_handle_timeout(ctx, desc); // 触发错误恢复流程
        return -ETIMEDOUT;
    }

    // ... (处理完成结果)
    return 0;
}

这里的 CONFIG_HDC_TASK_TIMEOUT_MS 是一个可配置的宏，允许根据不同场景（如训练 vs 推理）调整超时阈值，体现了设计的灵活性。

2.2 用户态 SDK 层的异步超时监控

在 SDK-driver 层，为了不阻塞用户主线程，driver 采用了异步模型。它通过独立的监控线程周期性地检查长时间未完成的任务。

在 src/sdk_driver/esched/event_scheduler.c 中，可以看到一个典型的监控循环：

// src/sdk_driver/esched/event_scheduler.c
static int event_monitor_thread(void *data)
{
    struct event_scheduler *sched = (struct event_scheduler *)data;
    struct event_node *node, *tmp;
    unsigned long current_time;

    while (!kthread_should_stop()) {
        current_time = jiffies;

        spin_lock(&sched->event_list_lock);
        list_for_each_entry_safe(node, tmp, &sched->pending_events, list) {
            // 检查事件是否超时 (例如超过 10 秒)
            if (time_after(current_time, node->submit_time + msecs_to_jiffies(10000))) {
                dev_warn(sched->dev, "Event %llu timed out, triggering recovery.\n", node->id);
                list_del(&node->list);
                spin_unlock(&sched->event_list_lock);

                // 异步触发恢复，避免持有锁时进行复杂操作
                schedule_work(&node->recovery_work);

                spin_lock(&sched->event_list_lock);
            }
        }
        spin_unlock(&sched->event_list_lock);

        // 休眠 100ms 后再次检查
        msleep(100);
    }
    return 0;
}

这种双层（内核同步等待 + 用户态异步监控）的超时检测体系，确保了无论在何种执行上下文中，系统都能及时感知并响应潜在的停滞。

---

三、错误恢复机制：构建自愈能力的核心

当超时或其他异常被检测到后，driver 必须有能力进行错误恢复，而非简单地崩溃。CANN driver 实现了一套分级、模块化的恢复策略。

3.1 黑匣子（Black Box, BBox）信息捕获

在尝试任何恢复操作之前，首要任务是保存现场。driver 的 bbox 模块（位于 src/ascend_hal/bbox/）负责在异常发生时，从硬件寄存器、内存等位置抓取关键诊断信息，并将其写入持久化存储。

// src/ascend_hal/bbox/bbox_core.c
void bbox_capture_on_error(struct device *dev, enum error_type type)
{
    struct bbox_context *ctx = get_bbox_context(dev);
    if (!ctx)
        return;

    // 1. 读取硬件状态寄存器
    u32 hw_status = readl(ctx->hw_status_reg_base + HW_STATUS_OFFSET);
    
    // 2. 抓取最后 N 条命令队列内容
    bbox_dump_cmd_queue(ctx, CMD_QUEUE_DUMP_SIZE);
    
    // 3. 保存当前进程上下文
    bbox_save_process_info(current);
    
    // 4. 将所有信息打包并写入 /var/log/cann/bbox/
    bbox_flush_to_disk(ctx, type);
    
    dev_crit(dev, "BBox captured for error type %d, saved to disk.\n", type);
}

这些“黑匣子”数据是后续根因分析的黄金标准。

3.2 分级恢复策略

driver 定义了多种恢复级别，从轻量级到重量级，按需触发：

1. 任务级恢复：仅重置当前失败的任务上下文，适用于孤立的算子错误。
2. 通道级恢复：重置 Host-Device 通信通道（HDC），清理消息队列。
3. 设备级恢复：执行完整的设备软复位（Soft Reset），重新初始化驱动状态机。

在 src/ascend_hal/dmc/device_monitor/recovery_manager.c 中，恢复管理器根据错误类型选择策略：

// src/ascend_hal/dmc/device_monitor/recovery_manager.c
int recovery_manager_handle_error(struct recovery_mgr *mgr, struct error_info *err)
{
    int ret = 0;

    switch (err->severity) {
    case ERROR_SEVERITY_TASK:
        ret = task_level_recovery(mgr, err);
        break;
    case ERROR_SEVERITY_CHANNEL:
        ret = channel_level_recovery(mgr, err);
        break;
    case ERROR_SEVERITY_DEVICE:
    default:
        // 触发设备级恢复前，先捕获黑匣子
        bbox_capture_on_error(mgr->dev, err->type);
        ret = device_level_soft_reset(mgr);
        break;
    }

    if (ret) {
        dev_err(mgr->dev, "Recovery failed, err=%d\n", ret);
        return ret;
    }

    dev_info(mgr->dev, "Recovery succeeded for error type %d\n", err->type);
    return 0;
}

这种分级策略最大限度地减少了恢复操作对系统整体性能的影响。

---

四、日志追踪体系：全链路可观测性的基石

强大的日志系统是稳定性的“眼睛”。CANN driver 构建了一个贯穿 DCMI、HAL、SDK 三层的日志追踪体系。

4.1 统一日志框架与动态分级

driver 定义了自己的日志宏，如 drv_log_debug, drv_log_info, drv_log_warn, drv_log_err，并支持在运行时动态调整日志级别，避免在生产环境中产生过多噪音。

// pkg_inc/driver_log.h
#define drv_log(level, fmt, ...) \
    do { \
        if (g_log_level >= LOG_##level) { \
            printk(KERN_##level "CANN-DRV [%s:%d] " fmt "\n", \
                   __func__, __LINE__, ##__VA_ARGS__); \
        } \
    } while (0)

// 使用示例
drv_log(INFO, "Submitting task with ID %llu", task_id);
drv_log(DEBUG, "HDC queue depth: %d", atomic_read(&hdc_ctx->queue_depth));

4.2 上下文关联与 Trace ID

为了追踪一个请求在多层间的流转，driver 引入了 Trace ID 的概念。当一个来自上层应用的请求进入 DCMI 层时，会生成一个唯一的 Trace ID，并将其传递给 HAL 和 SDK 层的所有相关日志。

// 在 DCMI 层入口
uint64_t trace_id = generate_unique_trace_id();
drv_log(INFO, "[TID:%llx] New inference request received", trace_id);

// 在 HAL 层处理时
drv_log(DEBUG, "[TID:%llx] Task submitted to hardware queue", trace_id);

// 在错误发生时
drv_log(ERR, "[TID:%llx] AI Core Error 0x%08x detected", trace_id, error_code);

运维人员只需搜索一个 Trace ID，即可完整复现一次请求的全生命周期，极大地简化了问题排查。

4.3 结构化日志与工具集成

driver 的日志格式经过精心设计，便于被上层的日志收集系统（如 Fluentd, ELK）解析。关键字段（如时间戳、模块名、Trace ID、错误码）均采用结构化输出，为自动化告警和分析提供了可能。

---

五、总结与展望

CANN driver 通过 精细化的超时检测、分级的错误恢复策略以及全链路的日志追踪体系，构建了一个坚实可靠的底层支撑。这三大机制相互协同，形成了一个闭环的稳定性保障网络：超时检测是“哨兵”，错误恢复是“医生”，而日志追踪则是“病历”。

未来，随着 CANN 生态的演进，driver 的稳定性机制有望进一步智能化，例如引入基于历史数据的异常预测、更细粒度的资源隔离以限制故障爆炸半径等。但无论如何演进，其核心目标始终不变：为上层 AI 应用提供一个稳定、高效、可信赖的运行环境。

---

相关链接：

• CANN 组织主页：https://atomgit.com/cann
• driver 仓库地址：https://atomgit.com/cann/driver