故障工单：sGPU 切片删除/重建并发场景触发内核 BUG（dma-fence.c:933）致节点 panic

1. 软硬件信息

服务器厂家：New H3C Technologies Co., Ltd.（新华三），型号 H3C R5300 G6（单节点 kubeadm 集群）
沐曦 GPU 型号：曦云 C500 64G × 4（BDF：0000:16:00.0 / 38:00.0 / 49:00.0 / 5a:00.0）
操作系统内核版本：Linux 5.15.0-191-generic（Ubuntu 22.04.5 LTS）
是否开启 CPU 虚拟化：已开启（Intel VT-x，/dev/kvm 存在）
mx-smi 回显：见下（2026-10-05 实测，完整回显另附 mx-smi-output.txt）

| 项目 | 值 |
|---|---|
| 驱动 KMD | 3.9.25 |
| MACA | 3.8.2.6 |
| BIOS / SMP | 1.35.4.0 |
| mx-smi | 2.3.4 |
| 集群 | Kubernetes（kubeadm 单节点）+ HAMi（metax 设备插件，量子切片调度） |
| panic 配置 | panic_on_oops=1，panic=10 |

mx-smi  version: 2.3.4
Attached GPUs                                     : 4
+---------------------------------------------------------------------------------+
| MX-SMI 2.3.4                       Kernel Mode Driver Version: 3.9.25           |
| MACA Version: 3.8.2.6              BIOS Version: 1.35.4.0                       |
|------------------+-----------------+---------------------+----------------------|
| Board       Name | GPU   Persist-M | Bus-id              | GPU-Util      sGPU-M |
| Pwr:Usage/Cap    | Temp       Perf | Memory-Usage        | GPU-State            |
|==================+=================+=====================+======================|
| 0     MetaX C500 | 0           Off | 0000:16:00.0        | 0%           Enabled |
| 72W / 350W       | 36C          P9 | 1104/65536 MiB      | Available            |
| 1     MetaX C500 | 1           Off | 0000:38:00.0        | 0%           Enabled |
| 58W / 350W       | 35C          P0 | 860/65536 MiB       | Available            |
| 2     MetaX C500 | 2           Off | 0000:49:00.0        | 0%           Enabled |
| 58W / 350W       | 34C          P0 | 860/65536 MiB       | Available            |
| 3     MetaX C500 | 3           Off | 0000:5a:00.0        | 0%           Enabled |
| 57W / 350W       | 34C          P0 | 860/65536 MiB       | Available            |
+---------------------------------------------------------------------------------+
| Sliced GPU                                                                      |
|------------------------------------+---------------------+----------------------|
| Minor    GPU    sGPU-Id    Compute | Vram Quota          | sGPU-Util            |
| 000      0      0          50%     | 244/32768 MiB       | 0%                   |
+---------------------------------------------------------------------------------+
| Process:                                                                        |
|  GPU                    PID         Process Name                 GPU Memory     |
|  0-s0                130738         python3                      244            |
+---------------------------------------------------------------------------------+

2. 故障现象

2026-10-04 09:38:05（UTC），节点内核日志最后一行：

kernel BUG at drivers/dma-buf/dma-fence.c:933!

随后内核 panic，节点自动重启（09:39:31 恢复）。panic 前无正常关机序列。pstore 为空、无 vmcore（kdump 未配置，后续我们会补上）。

3. 故障前操作时间线（UTC，精确到秒）

| 时刻 | 操作 / 事件 |
|---|---|
| 09:31 | 停止宿主机上一个运行中的 Docker 容器 comfy-l3（ComfyUI，持有卡0 的 sGPU：sgpu0，vram_quota=32768MiB，sched_quota=50） |
| 09:35:28 | 经 mx-smi sgpu -r <id> -i <card> 删除卡0 的 sgpu0（删除成功，卡0 余量 23587→56355MiB） |
| 09:35:49 | 一个新建的 k8s Pod（申请同一卡切片资源）进入 CrashLoop（反复创建/退出，设备插件随之处置设备引用） |
| 09:37:42 | 回退操作：在卡0 重建 sgpu0（32768MiB/50）。dmesg：METAX.B1600.D0.SGPU.INFO create sgpu0 ok, minor:0 |
| 09:37:51 | docker start comfy-l3（容器开始使用重建后的 /dev/sgpu000） |
| 09:38:05 | kernel BUG at drivers/dma-buf/dma-fence.c:933 → panic |

要点：删除切片 → 约 2 分 14 秒后重建同规格切片 → 容器启用 14 秒后内核崩溃；期间另有一个 CrashLoop Pod 在并发申请/释放 GPU 设备。

4. 历史关联现象（同机、同驱动版本，供交叉分析）

2026-10-03 15:00:17：METAX.B1600.D0.SGPU.ERROR sgpu mgr store, 'create' input invalid——在一次 16 段（4GiB×16，跨两卡 7+9）分配中，设备插件报告卡0 vram (4096) overflow, reset to (3107) 再 reset to (0) 后 create 返回 EINVAL，已建切片被回滚。当时卡0 有宿主机直建的 32GiB sGPU（非 k8s 纳管），驱动真实余量小于调度器账本。
2026-09-18（多条）：METAX.B1600.D0.SGPU.ERROR change sgpu0 sched quota failed, free 21 old 5 new 50。
正常使用路径（k8s 设备插件创建/删除 4096MiB/6% 量子切片）在过去两周高频运行无异常；09:39 重启后同路径复测（创建→使用→删除 4GiB 切片）亦正常。

5. 已保全证据（附件随工单提交，txt 格式）

| 附件文件 | 内容 | 行数 |
|---|---|---|
| kernel-bug-boot-minus1.txt | 崩溃 boot 完整内核日志（1.5MB） | 18236 |
| boot-minus1-tail.txt | 崩溃 boot 末尾 2000 行 | 2000 |
| kernel-bug-context.txt | BUG 行上下文 | — |
| mx-smi-回显-20261005.txt | mx-smi 完整回显（软硬件信息第 5 项） | 43 |
| rollback-rebuild-slice.txt / rollback-start-container.txt | 回退操作记录 | — |
| incident-sgpu-loss.txt / device-plugin-after-reboot.txt | CrashLoop Pod 与事故后设备插件快照 | — |

6. 请厂商评估与回答的问题

dma-fence.c:933 BUG 的根因：该 BUG() 在沐曦驱动的哪条路径触发？是否与「删除 sGPU 后快速重建同名/同卡切片 + 新消费者立即启用 + 并发设备申请/释放（CrashLoop Pod）」的竞态有关？
fence/引用计数生命周期：sgpu 删除时，已挂载给容器的 fence/dma-buf 引用如何回收？重建同名切片后，旧引用是否可能落到新对象上？
>32GiB 单切片支持：C500 单卡 vram_quota 上限（标称 65536MiB，实测每卡 64547MiB）下，单切片 61440MiB 是否受支持？（本次 09:38 前曾在空卡成功建删 61440MiB 单切片，但随后发生崩溃，两者是否相关请一并评估。）
create EINVAL 语义（10-03 事件）：sgpu mgr store, 'create' input invalid 的精确触发条件；vram overflow, reset to (3107)/(0) 的计算口径（是否含宿主机直建占用、保留量、槽位/碎片约束）。
可靠性建议：设备插件/平台侧推荐的 create/delete 时序约束（删除后应等待多久重建？是否需要 rescan？）；有无修复版驱动/固件、结构化 errno 或调试日志开关。
panic 规避：在修复版发布前，哪些操作序列必须避免？是否存在仅导致进程级失败而不触发内核 BUG 的配置（如关闭 panic_on_oops 是否安全）？
sGPU 模式不持久（2026-10-04 重启后实测新增）：内核 panic 重启后四卡 sGPU mode 全部回落 Disable（mx-smi sgpu --show-mode -i N），--show-remain 与 -c 均报 Operation not support in target device；须逐卡 mx-smi sgpu --enable -i N 手工恢复。问题：sGPU mode 不持久是否为预期行为？驱动能否提供开机自动 enable 的机制（持久化配置/模块参数/服务单元建议）？设备插件在 Disable 卡上配额探测失败即被调度排除（禁用→不分配→不 enable 死锁），官方对设备插件的 enable 时机有何建议？

7. 业务影响与临时措施

影响：平台中断约 2 分钟（节点自动重启恢复）；2 个pod会话被清理（重建，数据无损）；一个 GPU 服务（ComfyUI）停机约 9 小时（已于当日 18:43 +08 按保守序列恢复：逐卡 enable → 逐卡 4GiB canary → 建 32GiB 切片 → 静置 10 分钟 → 启动容器 → 再观察 10 分钟，全程内核零异常）。
临时措施（已执行）：冻结 >32GiB 单切片探索；切片删除/重建操作串行化、间隔 ≥10 分钟并加静置观察；生产窗口内冻结平台写入口；重启后逐卡手工 enable sGPU + 逐卡 canary；内核日志全量保全。
请厂商提供临时规避建议与修复版本计划。