[BUG] PVE 9.2 / 7.0.14-12-pve: Ryzen 9 7940HS Radeon 780M VCN/VAAPI faults followed by repeated host resets

[GWnerd]

I am also reporting this upstream to the AMD DRM/AMDGPU developers,
because the evidence currently points toward the AMDGPU/VCN path.

I am posting here as well because the affected kernel is
7.0.14-12-pve, and I would like to know whether this corresponds to a
known PVE kernel regression or whether an upstream AMDGPU fix is already
available/cherry-picked in a newer PVE kernel.

I have not changed kernels yet because I am trying to isolate one
variable at a time.

Summary
=======

I am seeing repeated complete-host resets on an AMD Ryzen 9 7940HS /
Radeon 780M (Phoenix) system while using the AMD VCN 4.0 video decode
engine through VA-API.

The workload is Frigate NVR running FFmpeg hardware-accelerated video
decoding inside an LXC container on Proxmox VE.

The kernel logs repeatedly identify FFmpeg as the process involved in
AMDGPU mmhub page faults and identify VCN as the faulty UTCL2 client.

During one affected boot, multiple VCN/mmhub faults were followed by a
kernel-mode page fault. Multiple subsequent/recent boots report that the
previous reset was caused by:

"an uncorrected error caused a data fabric sync flood event"

As a control test, I have disabled VA-API hardware decoding in Frigate
and moved FFmpeg decoding to the CPU. The test is currently in progress.
With VA-API disabled, there are no active FFmpeg processes using
renderD128/VAAPI and no new mmhub/VCN page faults have appeared so far.


Hardware
========

System:
GEEKOM A7 Max

CPU:
AMD Ryzen 9 7940HS
8 cores / 16 threads

Integrated GPU:
AMD Radeon 780M / Phoenix
PCI device: 1002:15bf

AMDGPU IP:
VCN v4.0
vcn_v4_0_0

Memory:
32 GB installed

BIOS:
American Megatrends
Version 1.26
Release date 2025-09-15


Host software
=============

Proxmox VE:
PVE 9.2
pve-manager 9.2.11

Affected running kernel:
7.0.14-12-pve

AMDGPU:
amdgpu kernel driver
/dev/dri/renderD128 exposed to Frigate LXC

Frigate container:
LXC 110
Debian 12
Docker

Frigate:
0.17.2-3d4dd3a

FFmpeg:
FFmpeg 7.0


Video workload
==============

Frigate was configured globally with:

ffmpeg:
hwaccel_args: preset-vaapi

There were approximately 11 concurrent Frigate FFmpeg detection
processes using arguments including:

-hwaccel vaapi
-hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi

and filters including:

scale_vaapi
hwdownload

Most camera detection streams are relatively low resolution and low
frame rate, approximately 640x360 at 5 fps.

The workload therefore does not appear to be unusually heavy for this
GPU.


Observed AMDGPU errors
======================

Example:

Sep 10 04:20:43
amdgpu 0000:c6:00.0: [mmhub] page fault
amdgpu 0000:c6:00.0: Process ffmpeg
amdgpu 0000:c6:00.0: Faulty UTCL2 client ID: VCN (0x1d)
amdgpu 0000:c6:00.0: PERMISSION_FAULTS: 0x3

A similar fault occurred again at:

05:01:51

and again at:

05:39:16

The 05:39 faults included:

MORE_FAULTS: 0x1
PERMISSION_FAULTS: 0x3

The address involved changed between some events, but the process was
again FFmpeg and the client was again VCN.


Kernel fault
============

At 06:33:10 during the same boot:

BUG: unable to handle page fault for address: fffffff79287023d
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page

The following boot at 06:33:35 reported:

Previous system reset reason [0x02000800]:
hardware watchdog timer expired


Repeated platform reset history
===============================

Boot starting 03:37:27:
Previous system reset reason [0x08000800]:
an uncorrected error caused a data fabric sync flood event

Boot starting 03:59:11:
Previous system reset reason [0x08000800]:
an uncorrected error caused a data fabric sync flood event

Boot starting 06:33:35:
Previous system reset reason [0x02000800]:
hardware watchdog timer expired

Boot starting 06:48:23:
Previous system reset reason [0x08000800]:
an uncorrected error caused a data fabric sync flood event

Boot starting 07:30:14:
Previous system reset reason [0x08000800]:
an uncorrected error caused a data fabric sync flood event

Thus four recent resets were recorded as uncorrected data-fabric
sync-flood events and one as a hardware watchdog expiration.


RAS / memory evidence
=====================

rasdaemon / ras-mc-ctl currently reports:

No Memory failure errors.
No MCE errors.

I therefore do not currently have evidence of a conventional ECC/MCE
memory error associated with the resets.


Networking
==========

The host's wired Realtek 2.5 GbE interface was also investigated because
the network controller reported client disconnects at approximately the
same times.

The interface negotiates:

2500 Mb/s
Full duplex

No carrier errors or repeated physical link-down events were found while
the host remained running.

The network "disconnect" events correlate with the host reboot times and
appear to be a consequence of the host resetting rather than the cause.


USB/storage investigation
=========================

There is a separate known issue with an external dual-bay ASMedia USB
storage enclosure which experienced disconnects on Sep 7.

However, on the Sep 10 crash boots inspected, both ASM235CM bridges and
both disks initialized normally.

I did not find the repeated USB disconnect / DID_NO_CONNECT / disk I/O /
EXT4 failure pattern immediately preceding these Sep 10 crashes.

Therefore I am treating that storage issue as a separate possible
confounder, not as the demonstrated cause of these crashes.


VA-API control test
===================

To isolate the VCN path, I changed only the Frigate global FFmpeg
configuration from:

ffmpeg:
hwaccel_args: preset-vaapi

to:

ffmpeg:
hwaccel_args: ""

Frigate was then restarted.

After the change:

- Frigate is healthy.
- No Frigate FFmpeg processes contain:
vaapi
renderD128
hwaccel
- FFmpeg decoding is therefore occurring on the CPU.
- No new AMDGPU mmhub/VCN page faults have appeared so far.

This A/B test is still running and I will update the report after a
longer stability period.

Importantly, I am not claiming yet that VCN is proven to be the root
cause. The current evidence shows a strong correlation and a plausible
trigger.


Related upstream report
=======================

There is a recent amd-gfx report dated Aug 24, 2026:

"VCN 4.0 ring reset cannot recover a power-gated block, taking down the
whole GPU (Phoenix, vcn_v4_0)"

That report involves:
Radeon 780M
Phoenix-family APU
vcn_v4_0_0
hardware accelerated video decode

The exact failure is not identical to mine, but the hardware block and
trigger are sufficiently similar that this may be related.


Expected result
===============

FFmpeg/VA-API video decoding through VCN should either operate normally
or, if a userspace/GPU submission fails, the AMDGPU driver should recover
without causing a kernel fault or complete platform reset.


Actual result
=============

FFmpeg VA-API decoding is associated with repeated AMDGPU mmhub
permission faults from the VCN client, followed in at least one observed
boot by a kernel supervisor page fault.

The system has also experienced multiple complete resets reported by
the AMD platform as uncorrected data-fabric sync-flood events.


Questions
=========

1. Is this a known Phoenix / VCN 4.0 issue?

2. Could the FFmpeg-triggered mmhub permission faults be related to the
subsequent kernel page fault or data-fabric sync-flood resets?

3. Is there a known fix or pending patch for vcn_v4_0_0 that I should
test?

4. Is this related to the recent report concerning VCN 4.0 ring reset
failure when the video block is power-gated?

5. Are there specific amdgpu debug parameters or traces that would be
useful to capture?

6. Is there a particular upstream kernel version or AMDGPU commit that
would be useful for an A/B test?

7. If a fix already exists upstream, is it suitable for stable
backporting to the Linux 7.0 / Proxmox kernel series?


I am willing to provide additional logs and test targeted patches or
kernel builds if useful.

 

[j.theisen]

Hi @GWnerd

thanks for posting on the forum!
There is a bug report [1] which sounds similar or at least has a similar workload as yours but seemingly different error messages and affected kernel 6.17.
Did these problems arise recently or did you provision the system with the reported 7.0.14-12?

In any case two routes to go down for rather quick results:
1. If an older kernel so 6.17, 6.14 or 6.8 worked fine before we are dealing with a regression. In this case please provide the last working version.
2. If you provisioned the system with kernel 7 and do not require ZFS support, you could try running the Ubuntu mainline kernel builds [2] and see if the issue persists there.
You can also try the newer 7.1 and 7.2 builds from there to see if a fix was already merged.

Best regards
Jonas

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=7420
[2] https://kernel.ubuntu.com/mainline/?C=N;O=D

 

[GWnerd]

Hello Jonas,

Thanks for the suggestions. I tested the older official Proxmox kernel route first.

I installed and booted 6.14.11-9-pve from the Proxmox repository and repeated the same Frigate workload. Unfortunately, the host still hard-reset on 6.14. Frigate was started at about 16:48:55, was fully running by 16:49:39, and the last normal log entries were at 16:56:44 before the host disappeared. There was no preserved kernel Oops, AMD-Vi fault, USB disconnect, EXT4 I/O error, or orderly shutdown immediately before the failure.

Because the same failure now occurs on both 7.0.14-15-pve and 6.14.11-9-pve, this does not currently look like a simple regression limited to the 7.0 kernel series.

I have also tested several kernel/platform variations:

• normal IOMMU behavior
• iommu.strict=1
• amd_iommu=off
• pcie_aspm=off

The host still hard-reset in all of those configurations. MemTest has previously passed, and I have not seen MCE/EDAC memory errors.

There is also an important storage/enclosure correlation that may be relevant. Frigate records to an 8 TB WD Purple drive connected through an older CENMATE dual-bay USB enclosure using an ASMedia hub/bridge path. A few days ago, during troubleshooting, both drives in that enclosure disappeared simultaneously and the Purple filesystem logged I/O/journal errors.

During that earlier troubleshooting, the ASMedia 174c:55aa bridge was also operating through the standard Linux usb-storage driver rather than UAS. Even with that storage-driver state, the later host resets still reproduced under Frigate load.

I then did a more controlled isolation test. With Frigate stopped and the CENMATE path removed, the Proxmox host remained stable. I reconnected only the 8 TB Purple in the CENMATE, leaving the separate 4 TB Time Machine drive physically disconnected, and started Frigate. The host again hard-reset. This has now reproduced more than once, including on the 6.14 kernel.

So at this point the strongest correlation is the combination of Frigate workload plus the 8 TB Purple through the older CENMATE/USB bridge path, although I am not yet calling the enclosure the confirmed root cause.

I have a new single-bay USB enclosure available for the next A/B test. My plan is to return to 7.0.14-15-pve and keep the same 8 TB Purple, same Frigate configuration, same host, and same workload, changing only the USB enclosure/bridge. That should help determine whether the old enclosure/USB path is the trigger.

If that test still resets the host, would you recommend trying one of the Ubuntu mainline kernels next, or is there any additional tracing/debug configuration you would like me to enable first?

Thanks again,

George

 

[CRCinAU]

I've had several issues in the past passing through an embedded / onboard GPU on a Ryzen 5700G. From memory, they sound to be similar to what you are saying.

That being said, I was setting this up inside a VM, not LXC.

I think you might be on the right path with the amdgpu issues - as I'm pretty sure it'll be down that path.