Dell PowerEdge R730xd PWR2262 硬重启调查报告
这篇记录不是“已经找到唯一根因”的结案文，而是基于这台 R730xd 最近几天的实际日志、配置变化和 A/B 测试，把已经确认的事实、已经排除的误判、仍然存在的疑点，以及下一步最有价值的测试整理到一起。
目前最关键的现象只有两个：第一，原先在虚拟机中让 Intel Arc A380 长时间承担多路 FFmpeg / VAAPI 视频负载时，服务器会间歇出现 PWR2262，随后发生硬复位；第二，停止这部分 GPU 负载后服务器出现了明显稳定期，而把 A380 临时交回 PVE 宿主机直接由 i915 驱动并进行 VAAPI 测试时，当次测试又没有复现硬重启。
因此现阶段不能简单把问题归结为“显卡坏了”或“电源坏了”。更合理的做法是把 GPU 负载、VFIO/VM、PCIe 资源分配、平台电源管理、PSU/BP0 供电链路 看成一组需要逐项拆开的变量。
当前结论
A380 工作负载与 PWR2262 有明显相关性，但现有证据不足以证明 A380 本体损坏。宿主机直接
i915 + VAAPI的测试没有立即复现故障，因此 VFIO/VM、PCIe BAR/MMIO、平台电源管理和供电瞬态的优先级已经上升。
一、故障环境
服务器为 Dell PowerEdge R730xd，运行 Proxmox VE。显卡是一张 Intel Arc A380，设备 ID 8086:56a5，DG2 / Alchemist 架构，子系统厂商为 GUNNIR / 蓝戟。A380 在 PVE 宿主机上的 PCI 地址为 0000:84:00.0，宿主机直接驱动时对应 /dev/dri/renderD128。
显卡原本通过 VFIO PCI Passthrough 直通给虚拟机，主要用于 FFmpeg / VAAPI 视频解码、缩放和编码。排查期间 PVE 使用过 6.17.x 与 7.0.x 系列内核，因此内核版本本身也必须作为变量保留。
宿主机识别 A380 的记录：
84:00.0 VGA compatible controller [0300]: Intel Corporation DG2 [Arc A380] [8086:56a5] (rev 05)
Subsystem: Shenzhen Gunnir Technology Development Co., Ltd Device [1ef7:1814]
Kernel driver in use: i915
Kernel modules: i915, xe二、PWR2262 到底说明了什么
iDRAC / Lifecycle Controller 记录的核心错误是：
PWR2262
The Intel Management Engine has reported an internal system error这台机器实际故障时还会紧接着出现 RAC0703 等硬复位相关事件。此前多次日志中，PWR2262 与整机 reset 之间形成了较稳定的时间关系，所以从现象上看，它和普通 Linux reboot、虚拟机重启或者单个服务崩溃完全不是一类问题。
Dell 官方针对 13G PowerEdge 的 PWR2262 文档确认，这个错误确实可能造成系统重启或故障，并把一个已知原因描述为 iDRAC 与 Intel Management Engine 之间的通信问题。官方文档针对旧固件环境给出的处理方法是更新 BIOS 和 iDRAC。
这里需要特别区分：Dell 的 KB 能证明 PWR2262 本身是一个真实的 13G 平台问题，但不能证明这台已经更新过固件的 R730xd 仍然是完全相同的旧固件原因。 如果 BIOS / iDRAC 已经升级，而 PWR2262 仍然出现，就必须继续调查其他变量。
一次典型故障可以概括为：
GPU / VM 正常工作
↓
PWR2262
Intel Management Engine internal system error
↓
RAC0703 / platform hard reset
↓
操作系统来不及正常关机
↓
整台 R730xd 重新启动三、最初怀疑过 PSU 和 BP0
这台机器的供电链路并不是完全“干净”的，因此早期把注意力放到 PSU 和背板上并没有错，只是后续证据表明不能直接把它们定性为根因。
当前两颗 PSU 均为 750W：
| 项目 | PSU1 | PSU2 |
|---|---|---|
| Dell PN | 00XW8WA00 | 05RHVVA00 / 5RHVV |
| 厂商 | EMSN / Emerson | Delta |
| 固件 | 00.11.3F | 00.24.7A |
| 功率 | 750W | 750W |
这里有两个已经纠正的误判。第一，PSU1 早期曾被错误识别成 Astec，后续通过 TSR / Inventory 数据确认实际为 Emerson / EMSN。第二，“Emerson + Delta 两个代工厂混装”本身也不能直接推出“不兼容”。真正应该看的是 Dell PN、额定规格、EPP、Health、Input、冗余状态，以及故障发生前后有没有真实的 PSU 状态变化。
TSR 中曾捕获到 PSU1 的一次短暂状态异常：
Status = 0x2000
INPUT = 0x8约 4 秒后恢复。这条记录很重要，因为它是少数直接来自 PSU 自身、且有明确时间戳的异常。但目前没有足够的官方 bit 定义，不能继续把 INPUT=0x8 扩大解释成某一种确定的 AC 输入故障。
与此同时，Lifecycle Log 还频繁出现：
HWC2003
BP0 Power Cable configuration error曾经在约 9 小时内看到接近 10 次状态变化，说明 BP0 背板供电链路或状态检测确实存在间歇性异常。但把时间轴和 PWR2262 对起来后发现，两者不是严格同步：部分事件相差数分钟甚至更久，也存在 PWR2262 前后没有新增 HWC2003 的情况。
因此目前对 BP0 的定位是：它是供电链路存在异常的旁证，但还不是已证实的 PWR2262 直接触发源。
四、真正改变排查方向的是 A380 负载
A380 在虚拟机里承担视频任务时，intel_gpu_top 曾记录到很高的媒体引擎占用：
intel-gpu-top: Intel Dg2 (Gen12)
Render/3D 0.00%
Blitter 0.00%
Video 63.79%
VideoEnhance 96.93%
Compute 0.00%同期存在多个 FFmpeg 进程：
PID MEM RSS NAME
9076 910664K 713140K ffmpeg
9976 1180456K 997652K ffmpeg
10070 531160K 440132K ffmpeg
10435 290284K 214424K ffmpeg
10627 250976K 185164K ffmpeg
9556 247376K 181628K ffmpeg这里最值得注意的是 VideoEnhance 接近 97%。也就是说，真正被压得很高的是 DG2 的媒体处理链路，而不是 Render/3D 或 Compute。
随后停止 A380 上的 FFmpeg / VAAPI 高负载，服务器开始出现明显稳定期。这个现象不能直接证明“显卡损坏”，但它足以把 GPU workload 提升为一个高优先级触发变量。
逻辑上至少存在四种可能：
- GPU 本体在高负载下发生异常；
- GPU 高负载带来的 PCIe / 供电瞬态触发平台问题；
- VFIO / QEMU / Guest i915 在某种设备状态切换下触发问题；
- 上述条件与 R730xd 的 ME、BIOS、电源管理或 PCIe 资源限制共同触发。
接下来的排查重点，就是想办法把这几个变量拆开。
五、先查温度，但 VM 里根本没有温度节点
最直观的怀疑是过热，所以先在虚拟机里检查 i915 hwmon：
for h in /sys/class/hwmon/hwmon*; do
echo "=== $h ==="
cat "$h/name" 2>/dev/null
grep . "$h"/temp*_input 2>/dev/null
done结果只有：
=== /sys/class/hwmon/hwmon0 ===
i915继续看 i915 实际暴露出来的 hwmon 节点：
device
energy1_input
fan1_input
in0_input
name
power
power1_max
power1_max_interval
power1_rated_max
subsystem
uevent可以看到能量、电压、风扇以及 power limit 相关节点，但就是没有 temp1_input。
直接读取也失败：
awk: cannot open "/sys/class/hwmon/hwmon*/temp1_input" (No such file or directory)Linux 内核文档明确规定，在支持该接口的 i915 平台上，temp1_input 表示 GPU package temperature，单位是毫摄氏度。因此这时候只能得出一个很有限的结论：Guest 中的当前 i915 环境没有暴露温度接口。
这时还不能说“A380 没有温度传感器”，因为也可能只是直通后的 telemetry 不完整。
六、XPU-SMI 也没有解决 VM 温度问题
为了绕过 hwmon，又尝试了 Intel XPU-SMI。
直接在 Debian 13 VM 中安装 XPU-SMI 2.1.0 时遇到依赖冲突：
xpu-smi : Depends: libze1 (>= 1.27.0) but 1.20.6-1 is to be installed
Depends: libze-intel-gpu1 but it is not going to be installed
Depends: libigsc1 but it is not installable这里没有继续硬改 Debian 的 GPU 用户态栈，因为 FFmpeg、VAAPI 和 Intel Media Driver 原本都在正常工作。为了一个监控工具去强行替换 Level Zero、Compute Runtime 等依赖，反而容易把正常的视频环境弄坏。
最后改用 Ubuntu 24.04 Docker 容器安装新版依赖。这个过程中又顺手踩到了 sing-box TUN 与 Docker 网络路径的问题：显式通过 127.0.0.1:7890 代理访问 Docker Registry 可以正常完成 TLS 并返回预期的 401，但普通 TUN 路径一度卡在 TLS 握手阶段。原 TUN 使用 172.19.0.1/30，与 Docker 常见的 172.19.0.0/16 网络存在冲突风险，后续将 TUN 地址改到 198.18.0.1/30 并调整 MTU 后，普通 curl 路径恢复正常。
容器里最终成功运行 XPU-SMI：
Intel XPU-SMI v2.1
Level Zero: 1.32.0设备发现正常：
Device ID: 0
Device Name: Intel(R) Arc(TM) A380 Graphics
Device State: normal
Vendor Name: Intel(R) Corporation
PCI BDF Address: 0000:01:00.0
DRM Device: /dev/dri/card1
Function Type: physical但温度仍然全部是：
GPU Core Temperature N/A
GPU Memory Temperature N/A
GPU VR Temperature N/A
Fan Speed (%) N/A同时可以读到一部分信息：
GPU Power: 18W / 47W
GPU Frequency: 600 MHz
GPU Memory Used: 18 MiB所以 VM 里两条不同路径得到了相同结果：
i915 hwmon → 没有 temp*_input
XPU-SMI / Level Zero → Temperature = N/A这进一步说明问题更像是 Guest / passthrough 下 telemetry 不完整，但当时仍不能排除软件栈差异。
七、把 A380 交回 PVE 后，温度立刻出现
为了得到真正有价值的 A/B 对照，停止 VM 100，并把 A380 临时从 VFIO 交回 PVE 宿主机的 i915。
这一步之后，宿主机出现：
/sys/bus/pci/devices/0000:84:00.0/hwmon/hwmon3/temp1_input实际读取：
54000也就是 54°C。连续观察几次大约为：
54°C
55°C
54°C这个结果解决了一个之前一直不确定的问题：A380 本体确实能够提供温度 telemetry。
因此更准确的结论是：
PVE Host + i915
→ 温度可读
VM + passthrough + Guest i915
→ 当前环境温度不可读这不能百分百证明“VFIO 本身过滤了温度”，因为 Host 与 Guest 的内核、驱动和用户态栈并不完全相同；但至少已经排除了“显卡根本没有温度传感器”这个方向。
八、宿主机 VAAPI 对照测试
A380 已经在 PVE Host 上，就顺便验证了 VAAPI 链路。
vainfo 正常识别 Intel iHD Driver，H.264、HEVC、VP9、AV1 等能力都可以看到。FFmpeg 也能识别：
av1_vaapi
h264_vaapi
hevc_vaapi
mjpeg_vaapi
mpeg2_vaapi
vp8_vaapi
vp9_vaapi先做了一次 30 秒单路测试，工作内容是把 1080p60 的测试源通过 VAAPI 上传到 GPU，缩放到 3840×2160，再使用 HEVC VAAPI 以 40Mbps 编码。
实测结果：
frame=1800
fps=119
time=00:00:29.98
speed=1.98x也就是说，这条 Host 路径不仅“能初始化”，而且确实完成了有效的媒体负载。
更关键的是，当次测试没有出现：
PWR2262
RAC0703
GPU Hang
整机硬复位后续继续做宿主机侧负载测试，当前反馈同样是“测试没有问题”。不过这里不应该夸大结论：目前保存下来的明确数据主要能证明 Host 侧负载测试没有在当次测试窗口内复现，不能据此宣称已经彻底排除 A380 或供电问题。
九、目前最有价值的 A/B 对照
现在已经形成一个比“猜哪块硬件坏了”更有用的对照：
| 场景 | GPU 路径 | 负载 | 结果 |
|---|---|---|---|
| 历史故障环境 | A380 → VFIO → VM → Guest i915 | 多路 FFmpeg / VAAPI | 曾出现 PWR2262 / 硬复位 |
| 停负载环境 | A380 仍在原环境，但媒体负载停止 | 空闲/低负载 | 出现明显稳定期 |
| Host 对照 | A380 → PVE i915 | VAAPI / FFmpeg | 当次测试未复现硬复位 |
这三组现象共同说明，下一步最该测试的不是“继续无脑烤 GPU”，而是把 VFIO/VM 与 GPU workload 这两个变量分开。
例如：
A380 → VFIO → VM，保持完全空闲如果长期稳定，而恢复媒体负载以后重新出现 PWR2262，说明 workload 是必要条件之一。
反过来，如果 GPU 只要回到 VFIO / VM、即使完全空闲也会复现，则应该重点转向设备 reset、PCIe、IOMMU、BAR/MMIO 与虚拟化路径。
十、PVE 6.17 不能忽略
这条线索后来重新值得关注，是因为 Proxmox 9.1 / Linux 6.17 在部分 Dell 13G 服务器上确实出现过与 PWR2262、Machine Check 和早期硬复位相关的问题。
Proxmox 社区中有 R630 在 6.17.2-2-pve 上启动即硬复位、而旧内核正常的案例；该案例最终通过启用 X2APIC 和 I/OAT DMA 恢复正常。Proxmox Staff 在同类讨论中也明确提到，一些 Dell 服务器在 6.17 下需要检查 SR-IOV Global 与 I/OAT DMA 等固件设置。
这并不等于“本机就是 6.17 bug”，因为本机故障触发条件和启动即重启的案例并不完全一样。但它证明了一件事：Dell 13G 的 ME / PECI / 平台固件与现代内核之间确实存在值得认真对待的交互变量。
因此 BIOS 中至少应该记录并核对：
X2APIC Mode
I/OAT DMA Engine
SR-IOV Global Enable
C-States / System Profile其中 C-State / Performance 方向也有 Dell 社区用户在更新 BIOS/iDRAC 后仍遇到 PWR2262、最后通过调整 C-State / Performance 获得改善的案例。这个证据等级低于 Dell 官方 KB，只能作为测试方向，不能写成已知根因。
十一、ReBAR / BAR 也是变量，但不是结论
VM 中运行 XPU-SMI 时反复看到：
WARNING: Resizable BAR not detected for device 0000:01:00.0宿主机初始化 A380 时也曾观察到尝试使用更大 BAR、最终因为平台资源限制回退到较小 BAR 后继续工作的情况。
因此可以确认这台老平台在 A380 上存在 BAR / MMIO 资源限制。不过目前没有任何证据能支持：
没有 ReBAR
=
PWR2262 根因它更适合放在 VFIO / PCIe 方向继续调查，而不是先入为主地当成答案。
十二、当前证据分级
为了避免后续再把猜测写成事实，这里把现有信息分成三档。
已经确认
- PWR2262 确实会伴随这台服务器的硬复位事件出现。
- A380 在 VM 内可以正常进行 FFmpeg / VAAPI 视频处理。
- VM 中曾实测
VideoEnhance接近 97%。 - 停止原 GPU 媒体负载后，服务器出现明显稳定期。
- VM 的 i915 hwmon 没有
temp*_input。 - VM 中 XPU-SMI 可以识别 A380，但温度是
N/A。 - PVE Host 直接使用 i915 时可以读取 A380 温度，约 54～55°C。
- Host 侧 VAAPI / FFmpeg 可以正常工作。
- 30 秒 1080p60 → 4K60 HEVC VAAPI 测试达到约 119 FPS / 1.98x。
- Host 侧当次负载测试没有立即复现 PWR2262。
有证据，但还不能确定因果
- GPU workload 与 PWR2262 的时间相关性。
- PSU1 曾出现短暂状态异常。
- BP0 曾频繁出现 HWC2003。
- VM / passthrough 环境存在温度 telemetry 缺失。
- A380 在当前平台存在 ReBAR / BAR 资源限制。
- Dell 13G + 新内核存在平台兼容性先例。
目前仍属于假设
- A380 本体损坏。
- A380 过热导致 PWR2262。
- 两颗不同厂商 PSU 混装就是根因。
- HWC2003 直接触发 PWR2262。
- ReBAR 缺失直接触发 PWR2262。
- Arc GSC 与 Intel ME 发生确定性的直接冲突。
- VFIO 是唯一根因。
- PVE 6.17 是唯一根因。
- CPU 或主板已经确定损坏。
十三、下一轮最有价值的测试
下一阶段不需要同时修改一堆 BIOS、PSU 和 VM 参数，否则一旦稳定了也不知道是哪项起作用。更合理的是每次只改变一个变量。
- 阶段 A： A380 重新交给 VFIO / VM，但保持 GPU workload 为 0，连续观察。
- 阶段 B： 如果 A 稳定，只恢复单路 FFmpeg / VAAPI，再观察。
- 阶段 C： 逐步提高到 2、4、6、8 路，同时记录
intel_gpu_top。 - 阶段 D： 如果只有 VM 负载能复现，检查 IOMMU、BAR/MMIO、设备 reset 和 Guest i915 日志。
- 阶段 E： 单独验证 X2APIC、I/OAT DMA、SR-IOV 与 System Profile/C-State。
- 阶段 F： 如果仍无法区分，再做 PSU 单电源 / 同型号 PSU / Riser 等硬件 A/B。
测试原则
一次只改一个变量。 如果同时换 PSU、改 BIOS、换内核、调整 VFIO 参数，即使故障消失，也很难知道真正有效的是哪一步。
十四、再次硬复位时应该保留什么
PWR2262 最大的问题是可能直接由平台硬复位，操作系统未必有机会把最后几秒日志完整写盘。因此下一次复现时，最重要的是把 故障前后的时间轴 拼起来，而不是只看单独一条报错。
重启后应该优先保存上一 boot 的 kernel journal 和完整 journal，再对齐 iDRAC Lifecycle Log。重点搜索：
i915
xe
mei
gsc
vfio
iommu
aer
pcie
mce
machine check
reset
hang
fault然后把下面几个时间放在同一张表里：
| 时间 | 事件 |
|---|---|
| T0 | FFmpeg workload 开始或负载变化 |
| T1 | Video / VideoEnhance 最后一次已知状态 |
| T2 | PSU / BP0 是否有状态变化 |
| T3 | PWR2262 |
| T4 | RAC0703 |
| T5 | 整机复位 |
真正有价值的是 PWR2262 前几十秒发生了什么。
十五、阶段性判断
目前最不支持的是“单纯显卡过热”。原因很直接：A380 在 Host 上可以正常读到 54～55°C 的温度，VAAPI 负载也能正常运行，而当前没有任何 thermal shutdown 或极端温度证据。
目前最值得优先验证的是：
A380 媒体负载
+
VFIO / QEMU / Guest i915
+
PCIe BAR / MMIO / IOMMU
+
Dell 13G 平台电源管理 / MEPSU 和 BP0 仍然留在嫌疑列表，因为确实存在真实异常日志；但现有时间关系还不足以证明它们直接触发每一次 PWR2262。
可以把当前故障树概括为：
flowchart TD A[PWR2262 + Hard Reset] B[A380 media workload] C[VFIO / QEMU / Guest i915] D[PCIe BAR / MMIO / IOMMU] E[Dell 13G ME / BIOS / power management] F[PSU / BP0 power path] G[GPU thermal] H[Host i915 VAAPI test] I[VM high media load] B --> A C --> A D --> A E --> A F --> A G -. current evidence weak .-> A H -->|当次未复现| J[Host path currently stable] I -->|历史上有相关性| A
这张图不是因果结论，而是下一步测试时的变量地图。
十六、最终结论
这轮排查真正获得的不是“某个部件已经确定坏了”，而是把问题从一个模糊的 PWR2262 缩小成了几个可以继续做 A/B 测试的方向。
最重要的三点是：
- A380 的媒体负载确实是目前最明显的触发相关变量。
- A380 在 PVE Host 直接由 i915 驱动时能够读温度并完成 VAAPI 负载测试，当次没有复现硬复位。
- 因此下一步应该优先区分“VFIO/VM 路径问题”和“GPU/供电本身问题”，而不是继续一次改很多东西。
如果后续能做到“VFIO + VM 空闲稳定，但一恢复媒体负载就复现”，问题范围会进一步缩小；如果只要把卡交回 VFIO 就能复现，则应优先查 PCIe / IOMMU / reset / BAR；如果 Host 长时间高负载最终也能复现，那么 PSU、Riser、平台供电和 A380 本体的优先级会重新上升。
这份记录暂时到这里，后续每次只追加新的实验条件、结果和时间戳，不再把未经验证的推测写成结论。