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）分配中，设备插件报告卡0vram (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；内核日志全量保全。
- 请厂商提供临时规避建议与修复版本计划。