title: Dell R730xd PWR2262 与 Intel Arc A380 硬重启排查记录
aliases:
- R730xd PWR2262 排查
- Arc A380 硬重启排查
- Dell R730xd GPU 故障记录
tags:
- Dell
- PowerEdge
- R730xd
- PWR2262
- Intel-ME
- Arc-A380
- i915
- VFIO
- Proxmox
- PVE
- VAAPI
- FFmpeg
- PCIe
- PSU
- Troubleshooting
created: 2026-09-07
updated: 2026-09-10
status: ongoing
severity: high
related:
- “Proxmox VE”
- “Intel Arc A380”
- “PWR2262”
- “GPU Passthrough”
Dell R730xd PWR2262 + Intel Arc A380 硬重启排查记录
故障概述
Dell PowerEdge R730xd 曾出现随机 PWR2262，随后由 iDRAC 触发硬件级复位。
后续排查过程中发现一个非常重要的现象：
停止 Intel Arc A380 的 FFmpeg / VAAPI 高负载后，服务器暂时不再发生突然硬重启。
目前这只能证明 GPU 负载与故障存在较强相关性，还不能直接证明 A380 本身损坏，也不能直接证明 PSU、PCIe、VFIO、Intel ME、GSC 中的某一个是唯一根因。
1. 服务器环境
1.1 服务器
设备：
Dell PowerEdge R730xd
虚拟化平台：
Proxmox VE / PVE
已使用过的 PVE 内核包括：
6.17.x-pve
7.0.x-pve
GPU：
Intel Arc A380
Device ID: 8086:56a5
架构：DG2 / Alchemist
显存：约 6 GB
宿主机 PCI 地址：
0000:84:00.0
显卡厂商信息：
Subsystem:
Shenzhen Gunnir Technology Development Co., Ltd
也就是 GUNNIR / 蓝戟版本 A380。
2. PWR2262 原始故障
R730xd 会突然发生硬重启。
iDRAC / Lifecycle Controller 中可以看到：
PWR2262
Intel Management Engine has reported an internal system error
并且此前观察到典型事件链：
PWR2262
↓
RAC0703
↓
SYS1001 / SYS1003
↓
硬件复位
↓
重新开机
PWR2262 到硬件 reset 之间的时间比较稳定，大约：
20～25 秒
这意味着它不是普通：
Linux kernel panic
systemctl reboot
VM reboot
而是更底层的平台 / iDRAC / Intel ME 相关复位。
3. 电源和背板历史异常
这部分是早期排查时发现的背景信息，目前仍然需要保留，但不能直接认定为唯一根因。
PSU 1
Part Number: 00XW8WA00
Vendor: EMSN / Emerson
Firmware: 00.11.3F
Power: 750 W
PSU 2
Part Number: 05RHVVA00
核心 PN: 5RHVV
Vendor: Delta
Firmware: 00.24.7A
Power: 750 W
曾经误把 PSU1 认成 Astec。
后续通过 TSR / inventory 数据确认：
PS1 = Emerson / EMSN
PS2 = Delta
因此：
已纠正
“Emerson + Delta 不同厂家 PSU 混装”本身不能直接证明 PSU 不兼容。
不能简单使用：
厂商不同
=
PSU 一定冲突
作为结论。
真正应该继续关注的是：
- PSU 最大输出功率是否匹配
- EPP / Dell 兼容性
- PSU 自身状态日志
- PSU 输入异常
- 背板供电异常
- GPU 负载变化时 PSU 是否发生状态切换
4. BP0 背板异常
此前 Lifecycle Log 中频繁出现：
HWC2003
BP0 Power Cable configuration error
而且不是只发生一次。
曾观察到：
约 9 小时内
BP0 Power Cable configuration error
反复红 / 绿状态变化近 10 次
因此背板供电链路本身存在值得排查的异常。
不过后续时间对照发现：
HWC2003
和：
PWR2262
并不是严格同时出现。
有时二者相差：
7～24 分钟
并且某些 PWR2262 前后根本没有新的 HWC2003。
因此目前更合理的判断是：
HWC2003
可能是供电系统存在异常的旁证
而不是：
HWC2003
一定直接触发 PWR2262
5. PSU1 曾出现短暂状态异常
TSR 数据中曾发现 PSU1 出现：
Status = 0x2000
INPUT = 0x8
约 4 秒后恢复正常。
这一条值得保留，因为这是少数精确到秒级的 PSU 异常记录。
但：
Warning
INPUT=0x8的具体 bit 定义仍应以 Dell / PSU 官方定义为准。
不能仅凭这一字段就百分百断言它等于某一种具体 AC 输入故障。
6. Arc A380 原始用途
A380 主要用于 FFmpeg 硬件视频处理。
虚拟机内部通过 PCI Passthrough 使用 GPU。
当时 intel_gpu_top 实际输出：
intel-gpu-top: Intel Dg2 (Gen12) @ /dev/dri/card1
ENGINES BUSY
Render/3D 0.00%
Blitter 0.00%
Video 63.79%
VideoEnhance 96.93%
Compute 0.00%
多个 FFmpeg 进程同时运行：
PID MEM RSS Video VideoEnhance 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 ≈ 96.93%
已经非常接近满载。
7. 第一个关键现象：停 GPU 负载后服务器稳定
在停止 A380 上的 FFmpeg / VAAPI 视频处理负载以后：
A380 高负载停止
随后观察到：
服务器没有继续突然硬重启
这成为整个排查中非常重要的新线索。
目前正确表述应为：
A380 GPU 高负载
与
PWR2262 / 硬重启
存在明显时间相关性
但暂时不能写成：
A380 已经确定损坏
或者：
GPU 温度就是根因
或者：
PSU 一定是根因
8. VM 内尝试读取 A380 温度
最初在运行 A380 的 Debian VM 内执行：
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
没有任何：
temp1_input
temp2_input
temp*_input
进一步查看：
for h in /sys/class/hwmon/hwmon*; do
name=$(cat "$h/name" 2>/dev/null)
if [[ "$name" == i915* ]]; then
echo "=== $h : $name ==="
ls "$h"
cat "$h"/temp*_input 2>/dev/null
fi
done
输出：
=== /sys/class/hwmon/hwmon0 : i915 ===
device
energy1_input
fan1_input
in0_input
name
power
power1_max
power1_max_interval
power1_rated_max
subsystem
uevent
再次证明：
VM 中 i915 hwmon 没有暴露 temperature node
直接尝试：
awk '{printf "%.1f °C\n", $1/1000}' \
/sys/class/hwmon/hwmon*/temp1_input
得到：
awk: cannot open "/sys/class/hwmon/hwmon*/temp1_input"
(No such file or directory)
9. 修正：intel_gpu_top 本身不显示 GPU 温度
早期排查曾错误认为：
intel_gpu_top
能够直接显示 Arc A380 温度。
这是错误信息。
实际 intel_gpu_top 主要可以显示：
Render/3D
Blitter
Video
VideoEnhance
Compute
频率
进程
显存
GPU engine utilization
但不是：
GPU temperature
因此后续温度排查改为：
hwmon
+
Level Zero / XPU-SMI
+
PVE 宿主机直接 i915
三条路线。
10. 尝试 XPU-SMI
为了验证：
Level Zero Sysman
能否绕过 hwmon 获取 A380 温度，开始安装 Intel XPU-SMI。
直接在 Debian 13 VM 安装最新版：
Intel XPU-SMI 2.1.0
下载成功：
xpu-smi_2.1.0+26.33.6468cec-1.24.04_amd64.deb
Size: 1.03 MB
但安装失败。
错误：
Unsatisfied dependencies:
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
完整关键错误：
Unable to satisfy dependencies.
xpu-smi:amd64=2.1.0+26.33.6468cec-1~24.04
Depends libze1 (>= 1.27.0)
but none of the choices are installable
11. 为什么没有继续污染 Debian 13
Debian VM 当时已经有一套能正常工作的：
A380
i915
Intel Media Driver
VAAPI
FFmpeg
为了一个监控程序去强行替换：
libze
IGC
GMM
Media driver
Compute Runtime
风险较高。
因此决定：
不直接污染 Debian GPU 用户态软件栈
改用 Ubuntu 24.04 Docker 容器进行 XPU-SMI 测试。
12. Docker pull 故障
尝试：
docker pull ubuntu:24.04
最初失败：
failed to resolve reference "docker.io/library/ubuntu:24.04"
failed to do request:
Head "https://registry-1.docker.io/v2/library/ubuntu/manifests/24.04":
EOF
当时服务器使用 sing-box TUN。
配置中：
{
"type": "tun",
"tag": "tun-in",
"address": [
"172.19.0.1/30"
],
"auto_route": true,
"strict_route": true,
"stack": "system",
"interface_name": "singtun0"
}
同时还有：
{
"type": "mixed",
"tag": "mixed-in",
"listen": "0.0.0.0",
"listen_port": 7890
}
13. 验证 sing-box 7890 代理
测试：
curl -v \
-x http://127.0.0.1:7890 \
https://registry-1.docker.io/v2/
结果完整建立 TLS：
HTTP/1.1 200 Connection established
TLSv1.3
SSL certificate verify ok
HTTP/2 401
返回：
{
"errors": [
{
"code": "UNAUTHORIZED",
"message": "authentication required",
"detail": null
}
]
}
这里：
HTTP 401
是正常现象。
它证明：
localhost:7890
↓
sing-box mixed inbound
↓
VLESS / Reality
↓
Docker Registry
这条路径是正常的。
14. TUN 路径 TLS 曾经异常
不用显式 7890 代理：
curl -v https://registry-1.docker.io/v2/
一开始会出现：
TLSv1.3 (OUT), TLS handshake, Client hello
TLSv1.3 (IN), TLS handshake, Server hello
TLSv1.3 (IN), TLS handshake, Encrypted Extensions
然后长时间卡住。
这个表现说明：
TCP 连接成功
ClientHello 成功
ServerHello 成功
但后续 TLS 数据传输异常
因此怀疑：
TUN MTU
路由
Docker bridge 网段冲突
15. sing-box TUN 修改
原地址：
172.19.0.1/30
存在与 Docker 常见：
172.19.0.0/16
冲突的风险。
后续修改为：
{
"type": "tun",
"tag": "tun-in",
"address": [
"198.18.0.1/30"
],
"mtu": 1400,
"auto_route": true,
"auto_redirect": true,
"strict_route": true,
"stack": "system",
"interface_name": "singtun0"
}
主要变化：
172.19.0.1/30
↓
198.18.0.1/30
增加：
auto_redirect = true
设置：
MTU = 1400
修改后再次测试：
curl -4 -v https://registry-1.docker.io/v2/
最终正常：
HTTP/2 401
因此：
Success
普通 TUN 路径下的 Docker Registry TLS 握手问题得到解决。
16. Ubuntu 24.04 Docker 容器
最终成功启动：
docker run --rm -it \
--privileged \
-v /dev/dri:/dev/dri \
-v /sys:/sys:ro \
ubuntu:24.04 bash
容器添加：
ppa:kobuk-team/intel-graphics
之后：
apt-cache policy \
libze1 \
libze-intel-gpu1 \
libigsc1 \
xpu-smi
得到：
libze1
Candidate:
1.32.0-1~24.04~ppa1
libze-intel-gpu1
Candidate:
26.31.39395.13-1~24.04~ppa1
libigsc1
Candidate:
1.2.0-1~24.04~ppa1
xpu-smi
Candidate:
2.0.1-1~24.04~ppa1
因此满足：
XPU-SMI 2.1.0
要求 libze >= 1.27
17. XPU-SMI 2.1.0 成功运行
容器里最终：
Level Zero Version: 1.32.0
执行：
xpu-smi
得到：
WARNING:
Resizable BAR not detected for device 0000:01:00.0
但是设备成功识别：
Intel XPU-SMI v2.1
Driver: unknown
Level Zero: 1.32.0
GPU：
GPU 0
Intel(R) Arc(TM) A380 Graphics
Bus:
0000:01:00.0
数据：
Fan: N/A
Temp: N/A
Power:
18W / 47W
Memory:
18 MiB / 6088 MiB
GPU Util:
N/A
18. XPU-SMI discovery
执行：
xpu-smi discovery
得到：
Device ID: 0
Device Name:
Intel(R) Arc(TM) A380 Graphics
Device State:
normal
Vendor:
Intel(R) Corporation
PCI BDF:
0000:01:00.0
DRM Device:
/dev/dri/card1
Function Type:
physical
因此可以明确：
Success
XPU-SMI 2.1.0 + Level Zero 1.32 确实能够发现消费级 Arc A380。
但属于部分 telemetry 支持。
19. XPU-SMI stats
执行：
xpu-smi stats -d 0
关键输出：
Metric Value
Device ID 0
PCI BDF 0000:01:00.0
Device Type discrete
Energy Consumed (J) 3.67
GPU Utilization (%) N/A
Compute Engines Util (%) N/A
Render Engines Util (%) N/A
Media Engines Util (%) N/A
Copy Engines Util (%) N/A
GPU Power (W)
Tile 0:
avg: 18
min: 18
max: 18
current: 18
GPU Frequency (MHz)
Tile 0:
avg: 600
min: 600
max: 600
current: 600
Media Frequency (MHz) N/A
Memory Frequency (MHz) N/A
Memory Voltage (V) N/A
GPU Core Temperature N/A
GPU Memory Temperature N/A
GPU VR Temperature N/A
Fan Speed (%) N/A
GPU Memory Read (kB/s) N/A
GPU Memory Write (kB/s) N/A
GPU Memory Bandwidth (%) N/A
GPU Memory Used (MiB)
Tile 0:
avg: 18
min: 18
max: 18
current: 18
GPU Memory Util (%) 0
PCIe Read N/A
PCIe Write N/A
Compute Engine Util
Engine 0: 0.0
Render Engine Util
Engine 0: 0.0
Decoder Engine Util
Engine 0: 0.0
Engine 1: 0.0
Encoder Engine Util
Engine 0: 0.0
Engine 1: 0.0
Copy Engine Util
Engine 0: 0.0
Media EM Engine Util
Engine 0: 0.0
Engine 1: 0.0
还出现：
Failed to get process count:
ZE_RESULT_ERROR_UNSUPPORTED_FEATURE
20. VM 内温度结论
至此使用两条不同路线：
i915 hwmon
以及：
Level Zero Sysman / XPU-SMI
结果：
i915:
没有 temp*_input
XPU-SMI:
GPU Core Temperature = N/A
GPU Memory Temperature = N/A
GPU VR Temperature = N/A
因此当时能够得出的严谨结论：
Important
在 VM / PCI Passthrough 环境中，当前驱动栈无法获取这张 Arc A380 的温度数据。
但还不能判断：
A380 硬件没有温度传感器
因为宿主机测试尚未进行。
21. ReBAR 警告
XPU-SMI 同时报告：
WARNING:
Resizable BAR not detected
说明虚拟机环境：
没有向 A380 提供有效 Resizable BAR
目前没有足够证据把它与：
PWR2262
直接关联。
所以：
ReBAR 缺失 = 已知问题/配置限制
ReBAR 缺失 = PWR2262 根因
后面这个等式目前不成立。
22. PVE 宿主机临时接管 A380
为了判断：
温度 N/A
究竟是：
A380 本身的问题
还是：
PCI Passthrough / VM 环境导致
停止 VM 100，并将 A380 从 VFIO 临时交还给 PVE 宿主机的：
i915
驱动。
结果：
A380 成功绑定 i915
PCI：
0000:84:00.0
23. 关键发现：宿主机能够读取 A380 温度
PVE 直接 i915 接管以后：
temp1_input
出现。
连续温度：
54°C
55°C
54°C
因此：
非常关键
Arc A380 硬件和宿主机 i915 完全能够提供温度数据。
VM 内温度消失不是因为：
A380 根本没有温度传感器
更可能与：
VFIO / PCI Passthrough
VM kernel / driver environment
telemetry interface
有关。
宿主机 hwmon 路径：
/sys/bus/pci/devices/0000:84:00.0/hwmon/hwmonX/temp1_input
后续实际得到：
HWMON=/sys/bus/pci/devices/0000:84:00.0/hwmon/hwmon3
温度：
54000
也就是：
54.0°C
24. A380 宿主机空闲功耗
通过：
energy1_input
变化推算：
空闲功耗约 18W
并且：
power1_max ≈ 47W
注意：
47W
是 power cap / power limit，而不是实时功耗。
25. 宿主机 i915 初始化情况
当时记录：
i915 驱动初始化成功
GuC 正常
HuC 正常
没有在 GPU 刚刚回归宿主机时立即产生新的：
PWR2262
当时最近的一次 ME 硬复位仍然是：
当天 04:09
26. i915 BAR 资源问题
宿主机 i915 初始化过程中还观察到：
尝试扩展至约 8 GB BAR 失败
随后：
回退到约 256 MB BAR
显卡仍然正常初始化。
因此这条记录目前归类为：
PCIe MMIO / BAR 资源限制
但：
Warning
目前没有足够证据证明 BAR 分配失败就是 PWR2262 的根因。
27. 宿主机第一次 GPU 压力测试脚本
最初准备脚本：
#!/bin/bash
set -eu
duration=${1:-600}
run_dir=$(mktemp -d /tmp/a380-load.XXXXXX)
sensor=/sys/bus/pci/devices/0000:84:00.0/hwmon
sensor_dir=$(find "$sensor" -mindepth 1 -maxdepth 1 -type d | head -n 1)
test "$(basename "$(readlink /sys/bus/pci/devices/0000:84:00.0/driver)")" = i915
test "$(qm status 100)" = 'status: stopped'
workers=()
cleanup() {
for worker in "${workers[@]}"; do
kill "$worker" 2>/dev/null || true
done
wait || true
}
trap cleanup EXIT HUP INT TERM
echo "START $(date -Is) boot=$(cat /proc/sys/kernel/random/boot_id) logs=$run_dir"
for stream in 1 2 3 4 5 6 7 8; do
timeout "$duration" ffmpeg \
-nostdin \
-hide_banner \
-loglevel error \
-vaapi_device /dev/dri/renderD128 \
-f lavfi \
-i 'testsrc2=size=1920x1080:rate=60' \
-vf 'format=nv12,hwupload,scale_vaapi=w=3840:h=2160' \
-c:v hevc_vaapi \
-b:v 40M \
-an \
-f null - \
>"$run_dir/stream-$stream.log" 2>&1 &
workers+=("$!")
done
start=$SECONDS
while (( SECONDS-start < duration )); do
temperature=$(cat "$sensor_dir/temp1_input") || exit 2
energy=$(cat "$sensor_dir/energy1_input") || exit 2
active=0
for worker in "${workers[@]}"; do
kill -0 "$worker" 2>/dev/null && active=$((active+1))
done
echo "$(date -Is) temp_mC=$temperature energy_uJ=$energy active=$active"
if (( temperature >= 85000 )); then
echo 'STOP temperature threshold'
exit 3
fi
if (( active == 0 )); then
cat "$run_dir"/*.log
echo 'STOP no workers'
exit 4
fi
sleep 2
done
echo "END $(date -Is)"
28. 第一次压力测试失败：宿主机没有 FFmpeg
运行：
./a380-load-test.sh
得到：
START 2026-09-08T12:26:48+08:00
boot=
9ba2dfb6-658e-4de3-8cec-e1be22c5c124
logs=
/tmp/a380-load.FyLubm
2026-09-08T12:26:48+08:00
temp_mC=55000
energy_uJ=275864735961
active=8
2026-09-08T12:26:51+08:00
temp_mC=55000
energy_uJ=275901020751
active=0
随后：
timeout: failed to run command ‘ffmpeg’:
No such file or directory
共 8 次。
最终：
STOP no workers
所以：
Warning
这次不算 GPU 压力测试。
A380 实际没有得到 FFmpeg 负载。
29. PVE 安装 FFmpeg
准备安装：
apt install -y \
ffmpeg \
vainfo \
intel-media-va-driver \
intel-gpu-tools
一开始 PVE APT 被设置为通过：
10.10.0.2:7890
代理。
但当时目标代理不可达：
Could not connect to 10.10.0.2:7890
No route to host
因此临时禁用 APT 代理：
apt \
-o Acquire::http::Proxy=false \
-o Acquire::https::Proxy=false \
update
成功：
Hit: Debian trixie
Hit: Proxmox repository
All packages are up to date
30. APT lock 情况
随后再次安装时遇到：
Could not get lock:
/var/lib/dpkg/lock-frontend
held by process:
131659
查看：
ps -fp 131659
得到：
apt-get \
-o Acquire::http::Proxy=DIRECT \
-o Acquire::Retries=0 \
install -y \
--no-install-recommends \
ffmpeg \
intel-media-va-driver \
intel-gpu-tools
实际上旧的 apt 正在安装这些软件。
因此没有粗暴删除：
/var/lib/dpkg/lock*
31. dpkg 安装日志
/var/log/dpkg.log 中可以看到：
2026-09-08 12:28:07
install ffmpeg:amd64
7:7.1.5-0+deb13u1
2026-09-08 12:28:20
status unpacked ffmpeg:amd64
7:7.1.5-0+deb13u1
之后完成配置：
2026-09-08 12:34:32
configure ffmpeg:amd64
2026-09-08 12:34:32
status installed ffmpeg:amd64
最终：
ii ffmpeg
ii intel-gpu-tools
ii intel-media-va-driver
版本：
ffmpeg:
7:7.1.5-0+deb13u1
intel-gpu-tools:
2.0-1
intel-media-va-driver:
25.2.3+dfsg1-1
32. vainfo 安装
另外安装：
vainfo 2.22.0
libva-wayland2 2.22.0
成功。
33. 确认 A380 render node
执行：
readlink -f \
/dev/dri/by-path/pci-0000:84:00.0-render
结果：
/dev/dri/renderD128
所以 A380 对应：
/dev/dri/renderD128
34. 确认宿主机 GPU 驱动
84:00.0 VGA compatible controller:
Intel Corporation DG2 [Arc A380]
[8086:56a5]
Subsystem:
Shenzhen Gunnir Technology Development Co., Ltd
Kernel driver in use:
i915
Kernel modules:
i915, xe
因此压力测试期间：
A380
→ i915
而不是：
A380
→ vfio-pci
35. VAAPI 验证
执行：
vainfo \
--display drm \
--device /dev/dri/renderD128
结果：
VA-API version:
1.22
Driver:
Intel iHD driver
25.2.3
关键支持：
H.264 decode
H.264 encode
HEVC decode
HEVC encode
VP9 decode
VP9 encode
AV1 encode
其中：
VAProfileAV1Profile0
VAEntrypointEncSliceLP
说明：
A380 AV1 硬件编码
被正确识别。
36. FFmpeg VAAPI encoder
FFmpeg 显示：
av1_vaapi
h264_vaapi
hevc_vaapi
mjpeg_vaapi
mpeg2_vaapi
vp8_vaapi
vp9_vaapi
因此 FFmpeg VAAPI 链路正常。
37. intel_gpu_top 宿主机识别
card0
102b:0534
card1
Intel Dg2 (Gen12)
└─renderD128
因此：
renderD128 = Arc A380
进一步确认。
38. 宿主机温度再次确认
实际：
HWMON=
/sys/bus/pci/devices/0000:84:00.0/hwmon/hwmon3
读取：
cat "$HWMON/temp1_input"
得到：
54000
即：
54°C
这是整个排查里非常关键的数据。
39. 30 秒单路 A380 VAAPI 实测
执行：
ffmpeg \
-nostdin \
-hide_banner \
-loglevel info \
-vaapi_device /dev/dri/renderD128 \
-f lavfi \
-i 'testsrc2=size=1920x1080:rate=60' \
-vf 'format=nv12,hwupload,scale_vaapi=w=3840:h=2160' \
-c:v hevc_vaapi \
-b:v 40M \
-t 30 \
-an \
-f null -
输入：
1920x1080
60 FPS
testsrc2
GPU 执行：
VAAPI upload
+
scale_vaapi
1920×1080
→
3840×2160
+
HEVC VAAPI encode
40 Mbps
实际输出：
Video:
hevc Main
Resolution:
3840x2160
Frame rate:
60 fps
Bitrate:
40000 kb/s
30 秒结果：
frame=1800
fps=119
time=00:00:29.98
speed=1.98x
因此：
Success
A380 在 PVE 宿主机直接使用 i915 + VAAPI 的情况下，可以正常完成：
1080p60
↓
GPU scale
↓
4K60
↓
HEVC VAAPI
实际处理速度约：
119 fps
≈ 1.98x realtime
这次测试没有立即发生：
PWR2262
硬复位
GPU hang
40. 后续宿主机 GPU 压力测试
之后继续进行了 A380 宿主机负载测试。
测试目标包括：
1 stream
2 streams
4 streams
6 streams
8 streams
脚本设置温度保护线：
85°C
也就是：
if (( temperature >= 85000 )); then
echo "STOP temperature threshold"
exit 3
fi
同时记录：
temperature
energy
active ffmpeg worker count
用户后续反馈：
宿主机测试没有发现问题
即至少在此次测试阶段：
A380
+
PVE i915
+
VAAPI
+
FFmpeg GPU load
没有立即复现此前的硬重启。
41. 这条结果非常重要
此前：
VM / VFIO 环境
+
A380 多路视频负载
+
PWR2262 / 硬复位
而现在：
PVE bare host
+
i915
+
A380 VAAPI load
没有立即复现。
因此嫌疑模型从：
A380 单纯一有负载就导致 R730xd 崩溃
开始转向更复杂的：
A380
+
VFIO
+
VM
+
特定负载
+
PCIe / BAR / MMIO
+
平台固件
+
电源管理
组合问题。
42. 当前故障相关性的正确表述
目前不能说：
A380 已经排除
也不能说：
A380 已经确定是根因
应该写成：
Important
A380 / GPU 工作负载仍然是重要触发变量。
但是：
A380 在 PVE 宿主机直接 i915 控制下
可以承受至少一定程度的 VAAPI GPU 负载
而没有立即造成 PWR2262
因此“单纯 GPU 核心高负载/单纯温度过高”目前不像最强解释。
43. 温度假设目前明显减弱
目前已知：
GPU idle:
54～55°C
而宿主机测试正常。
没有观察到：
85°C+
或者：
GPU thermal shutdown
所以暂时没有证据支持：
A380 温度过高
→
服务器硬重启
如果未来硬重启时能够记录：
GPU 例如只有 60～70°C
却仍然：
PWR2262
那么可以进一步削弱“热保护”假设。
44. 当前主要嫌疑排序
截至目前，我会把可能性大致分成：
A. VFIO / VM / PCIe 平台交互
重点怀疑：
VFIO passthrough
PCIe reset
MMIO
BAR
Resizable BAR
IOMMU
QEMU
i915 guest driver
原因：
宿主机 i915 测试正常
VM 场景曾经出现问题
B. GPU 负载引发平台供电瞬态
仍不能排除：
GPU load
↓
PCIe / PSU / VRM transient
↓
ME / DMI / PECI instability
↓
PWR2262
尤其服务器还存在：
HWC2003
PSU1 历史异常状态
这些背景。
C. R730xd 与 Arc A380 平台兼容问题
R730/R730xd 是：
Intel Xeon E5 v3/v4
Dell 13G
Arc A380 是多年以后出现的设备。
因此：
PCIe BAR
Above 4G decoding
ReBAR
Option ROM
GSC
ME
固件
组合兼容问题值得考虑。
D. Intel GSC / ME 交互
网络上曾检索到一个非常接近的案例：
Dell PowerEdge R730
+
Proxmox
+
Intel Arc A380
+
PWR2262
+
随机硬重启
对方同样观察到：
停止 GPU 相关 workload
→
服务器稳定数天
最终移除 Arc 后问题消失。
对方怀疑：
Arc GSC
与平台：
Intel ME
存在交互。
但这部分目前只属于：
用户经验 + 推测
还没有足够官方证据证明：
Arc GSC
直接导致
R730 ME PWR2262
因此不能写成确定结论。
45. PVE 6.17 相关变量
另一个需要保留的重要变量是：
PVE kernel 6.17
曾有其他 Dell 13G 用户报告：
PWR2262
CPU0704
UEFI0078
和：
Proxmox 6.17 kernel
相关。
其中有案例通过 BIOS：
X2APIC
I/OAT DMA
设置改善。
因此如果以后：
宿主机 A380 压力测试没问题
VM 恢复后仍出现 PWR2262
也需要继续对比：
PVE 6.17
vs
其他稳定内核
而不能只盯显卡。
46. GPU 返回 VM
宿主机测试完成后，需要将 GPU 从：
i915
重新交回：
vfio-pci
建议操作：
GPU="0000:84:00.0"
VMID="100"
qm status "$VMID"
lspci -nnk -s "$GPU"
echo "$GPU" \
> "/sys/bus/pci/devices/$GPU/driver/unbind"
modprobe vfio-pci
echo vfio-pci \
> "/sys/bus/pci/devices/$GPU/driver_override"
echo "$GPU" \
> /sys/bus/pci/drivers_probe
lspci -nnk -s "$GPU"
qm start "$VMID"
qm status "$VMID"
目标状态：
Kernel driver in use:
vfio-pci
然后：
VM 100
status: running
Note
本次聊天中没有继续贴出最终
qm start 100后的完整执行输出，因此以后需要确认：
84:00.0 是否确实已恢复 vfio-pci
VM 100 是否正常拿到 A380
47. 如果 A380 还有 84:00.1
Arc A380 可能还有：
84:00.1
HDMI / DP Audio
可以检查：
lspci -nnk -s 84:00
如果 VM 配置使用整个：
0000:84:00
则 .1 也应检查是否需要：
vfio-pci
48. 当前已确认事实
CONFIRMED
以下内容已经通过实际测试确认：
1.
Arc A380 在 VM 里面能够正常进行 FFmpeg / VAAPI 视频处理。
2.
VM 里的 intel_gpu_top 可以看到：
Video
VideoEnhance
FFmpeg PID
显存占用。
3.
VM 内 i915 hwmon 没有 temp*_input。
4.
VM 内 XPU-SMI 2.1 + Level Zero 1.32 能识别 Arc A380。
5.
VM 内 XPU-SMI 温度全部 N/A。
6.
PVE 宿主机直接 i915 接管 A380 后，
temp1_input 正常出现。
7.
宿主机空闲 A380 温度约：
54～55°C。
8.
宿主机空闲功耗约：
18W。
9.
A380 power cap 大约：
47W。
10.
A380 宿主机 VAAPI 正常。
11.
HEVC / H264 / AV1 VAAPI encoder 正常。
12.
宿主机单路：
1080p60 → 4K60 + HEVC VAAPI
30 秒测试正常。
13.
实际达到约：
119 fps / 1.98x realtime。
14.
测试过程中没有立即发生 PWR2262。
15.
停止原 VM GPU workload 以后，
服务器出现明显稳定期。
49. 当前尚未证明的内容
NOT PROVEN
以下内容仍然只是怀疑：
A380 本体损坏
A380 温度过高导致重启
Emerson + Delta PSU 厂商不同就是根因
HWC2003 一定直接导致 PWR2262
ReBAR 缺失一定导致 PWR2262
Arc GSC 一定与 R730 Intel ME 冲突
GPU 47W 功耗一定导致 PSU 过载
VFIO 一定是唯一根因
PVE kernel 6.17 一定是根因
这些都还需要进一步实验。
50. 当前最重要的实验结论
当前最有价值的 A/B 对照是：
场景 A：
A380
→ VFIO
→ VM
→ 多路 FFmpeg workload
历史：
曾出现 PWR2262 / 硬重启
对比：
场景 B：
A380
→ PVE i915
→ Host VAAPI workload
结果：
目前压力测试正常
未立即复现 PWR2262
因此下一阶段应该重点回答：
究竟是 GPU load 本身导致问题
还是：
GPU load
+
VFIO / QEMU / VM
+
R730xd 平台
才会触发问题。
51. 推荐的下一阶段 A/B 测试
Test A：宿主机长期 GPU 压力
A380 → i915 → PVE
持续：
30 min
1 h
2 h
观察：
temperature
power
Video
VideoEnhance
dmesg
PWR2262
HWC2003
PSU state
如果长期完全稳定：
“GPU 单纯满载”
嫌疑明显下降。
Test B：GPU 返回 VFIO，但 VM 不启动 workload
A380 → VFIO → VM
但：
FFmpeg workload = 0
观察：
24～48 h
如果稳定：
仅仅 PCI passthrough
可能不是充分触发条件。
Test C：VM 内单路负载
1 路 FFmpeg
观察。
然后：
2 路
4 路
6 路
8 路
阶梯增加。
目标是找：
故障阈值
而不是简单“烤机”。
52. 如果再次硬重启，必须立即保存的东西
重启后不要立刻继续跑负载。
首先记录：
date -Is
uptime
journalctl -b -1 -k \
--no-pager \
> /root/kernel-previous-boot.log
journalctl -b -1 \
--no-pager \
> /root/journal-previous-boot.log
搜索：
journalctl -b -1 -k --no-pager |
grep -Ei \
'i915|xe|mei|gsc|vfio|iommu|aer|pcie|hang|reset|fault|error'
同时立即导出：
iDRAC Lifecycle Log
SEL
TSR
尤其记录：
PWR2262 时间
RAC0703 时间
HWC2003 时间
PSU 状态变化时间
53. 最有价值的时间关联
以后最好做时间表：
| 时间 | GPU 状态 | GPU 温度 | GPU 功耗 | Video | VE | PSU | LC Log |
|---|---|---:|---:|---:|---:|---|---|
| 12:00:00 | idle | 55°C | 18W | 0% | 0% | OK | - |
| 12:10:00 | 1 stream | ? | ? | ? | ? | OK | - |
| 12:20:00 | 4 streams | ? | ? | ? | ? | OK | - |
| 12:30:00 | 8 streams | ? | ? | ? | ? | ? | ? |
| X | reboot | last value | last value | last value | last value | ? | PWR2262 |
真正需要找的是：
PWR2262 前几秒
到底发生了什么。
54. 推荐长期记录脚本
最好将测试日志放到：
/var/log/a380-load/
而不是：
/tmp/
因为如果硬复位：
/tmp
不是理想的故障证据保存位置。
应持续记录：
timestamp
boot_id
GPU temperature
energy counter
estimated power
active FFmpeg workers
这样如果：
机器突然 reset
重启以后仍可以查看：
最后一次成功写盘的数据
55. 当前故障树
flowchart TD A[R730xd PWR2262 + Hard Reset] A --> B[Intel ME / PECI / DMI 异常] A --> C[供电异常] A --> D[PCIe / VFIO / VM] A --> E[PVE Kernel / BIOS] A --> F[Arc A380] C --> C1[PSU1 历史异常] C --> C2[BP0 HWC2003] C --> C3[GPU 负载瞬态] C --> C4[Riser / Slot Power] D --> D1[VFIO] D --> D2[IOMMU] D --> D3[BAR / MMIO] D --> D4[QEMU] D --> D5[ReBAR Missing] E --> E1[PVE 6.17] E --> E2[X2APIC] E --> E3[I/OAT DMA] F --> F1[GPU load] F --> F2[GSC] F --> F3[i915 / xe] F --> F4[Temperature] F4 --> G[Host temp 54-55C] G --> H[目前无过热证据] F1 --> I[Host VAAPI Stress] I --> J[目前测试正常] F1 --> K[VM VAAPI Workload] K --> L[历史上与 PWR2262 有相关性]
56. 当前判断
截至本次记录：
Summary
最值得继续调查的已经不是“A380 有没有温度传感器”这个问题。
这个问题已经解决：
A380 有温度
PVE i915 可以读
VM / VFIO 环境读不到
当前真正需要解决的是：
为什么 A380 在原 VM workload 场景中
与 PWR2262 / 硬重启高度相关，
但回到 PVE 宿主机直接 i915 压力测试时
暂时没有立即复现。
57. 当前优先排查顺序
目前暂定：
1. VM / VFIO / GPU workload 组合问题
2. PCIe / BAR / MMIO / Riser
3. GPU 负载导致平台供电瞬态异常
4. R730xd + Arc A380 平台兼容
5. PVE kernel 6.17 / BIOS 功能
6. PSU / BP0 间歇异常
7. Intel ME 自身 PWR2262 历史 bug
8. 单纯 GPU 过热
其中：
“单纯 GPU 过热”
目前优先级已经明显降低。
58. 后续 TODO
-
确认 A380 已重新绑定
vfio-pci -
确认 VM 100 正常启动
-
VM 空闲 24～48 小时观察 PWR2262
-
VM 1 路 VAAPI 测试
-
VM 2 路 VAAPI 测试
-
VM 4 路 VAAPI 测试
-
VM 6 路 VAAPI 测试
-
VM 8 路 VAAPI 测试
-
每一级记录
intel_gpu_top -
每一级记录功耗
-
每一级记录 iDRAC PSU 状态
-
再次故障立即导出 LC Log
-
再次故障立即保存上一 boot journal
-
核查 PVE kernel 版本与故障发生时间
-
检查 BIOS X2APIC
-
检查 BIOS I/OAT DMA
-
检查 Above 4G Decoding
-
检查 VM PCIe BAR / MMIO 设置
-
检查 GPU 所在 Riser 和供电
-
检查 BP0 电源线
-
对照单 PSU / 双 PSU 运行
-
必要时更换 PSU 做 A/B 测试
-
必要时换另一张 GPU 做 A/B 测试
59. 最终阶段性结论
目前最重要的三个发现：
发现 1
停止 VM 中 A380 高负载以后
R730xd 暂时不再突然硬重启
这是非常有价值的相关性证据。
发现 2
VM：
无法读取 A380 温度
PVE Host：
可以读取 A380 温度
54～55°C
因此温度 telemetry 的缺失与：
VM / Passthrough 环境
高度相关。
发现 3
A380 回归 PVE Host i915 后
VAAPI 初始化正常
HEVC encode 正常
AV1 encode capability 正常
1080p60
→
4K60 HEVC VAAPI
30 秒：
1800 frames
119 FPS
1.98x realtime
没有立即发生硬复位
这一条非常重要。
它说明：
A380 GPU 一工作
=
R730xd 必然 PWR2262
这个简单假设目前并不成立。
下一步应该重点验证：
A380
+
VFIO
+
VM
+
多路视频负载
这个组合是否才是真正的触发环境。
60. 一句话总结
当前证据表明 A380 GPU 负载与 R730xd 的 PWR2262 硬重启存在明显相关性，但 A380 在 PVE 宿主机 i915 下能够正常读取 54～55°C 温度并完成 VAAPI 负载测试而未立即复现故障，因此现阶段更应怀疑 VFIO/VM/PCIe/供电/平台兼容等组合条件，而不是简单认定为 GPU 过热或 A380 本体损坏。
相关笔记