Dear Maintainer,
I am reporting a reproducible amdgpu/VCE regression on Debian 13 (trixie)
with an AMD Radeon RX 480 / Polaris10 GPU. Active RustDesk remote-control
sessions are stable on Debian kernel 6.12.101-1 but trigger a VCE ring timeout
and GPU reset on 6.12.105-1 and 6.12.107-1.
Expected behavior
=================
Active RustDesk screen-capture and remote-control sessions should not wedge
the VCE engine, reset the GPU, or terminate the graphical desktop.
Actual behavior
===============
On 6.12.105 and 6.12.107, an active RustDesk session reproducibly reaches:
RustDesk active session -> amdgpu ring vce0 timeout naming rustdesk
-> GPU reset
The severe 6.12.105 runs additionally reached:
-> VCE suspension failure -> VRAM loss -> X11/GNOME session teardown
-> GDM
The controlled 6.12.107 run was stopped at the predetermined failure
boundary after the RustDesk connection froze, the vce0 timeout named
RustDesk, and GPU reset began. That particular run did not record VRAM loss
or full X11 teardown.
System and userspace
====================
* Debian GNU/Linux 13.6 (trixie), amd64
* AMD Radeon RX 480 / Polaris10, PCI ID 1002:67df, amdgpu
* GNOME/GDM X11
* RustDesk 1.4.9
* Official native RustDesk Debian package and package-provided system service
are the primary reproducer
* firmware-amd-graphics 20250410-2
* Mesa 25.0.7-2+deb13u1
* No NVIDIA hardware, installed NVIDIA userspace, or loaded NVIDIA module
participates in the final reproducer
The native RustDesk package came from the official rustdesk/rustdesk 1.4.9
release. The Debian asset was rustdesk-1.4.9-x86_64.deb, SHA-256:
7244ba47c40e804172044bfbe659467c54ce46554c98e78c8c0406f1d612fda3.
Regression matrix
=================
* linux-image-6.12.101+deb13-amd64 6.12.101-1: PASS / stable
* linux-image-6.12.105+deb13-amd64 6.12.105-1: FAIL
* linux-image-6.12.107+deb13-amd64 6.12.107-1: FAIL
6.12.105 repeatedly failed during RustDesk sessions. Flatpak RustDesk 1.4.9
independently reproduced the failure, and the official native RustDesk 1.4.9
package/system service reproduced it in a controlled test after approximately
30 seconds.
The official native RustDesk 1.4.9 service reproduced on 6.12.107 after
approximately 15 seconds of active remote use.
On the same hardware and substantially the same userspace and RustDesk
configuration, native RustDesk repeatedly passes on 6.12.101. Successful
tests include interactive use, control at GDM, GDM-to-GNOME transitions,
logout/login, sustained sessions, disconnect/reconnect cycles, and a final
7,201-second unattended monitor (1,355 samples) with zero VCE timeout, GPU
reset, VRAM-loss, or graphical-session teardown events.
This packaging-independent result shows that the observed regression is not
specific to the Flatpak sandbox or packaging. I am not claiming that RustDesk
itself is conclusively innocent or that a particular upstream commit is
responsible. The evidence establishes a kernel/AMDGPU/VCE regression, or a
kernel-specific interaction, triggered by this workload; source-level cause
has not yet been isolated.
Representative 6.12.105 native-service failure
================================================
amdgpu: ring vce0 timeout, signaled seq=63, emitted seq=64
amdgpu: Process information: process rustdesk pid 4790 thread rustdesk:cs0 pid 7411
amdgpu: GPU reset begin!
amdgpu: failed to suspend display audio
suspend of IP block <vce_v3_0> failed -22
amdgpu: GPU reset succeeded, trying to resume
[drm] VRAM is lost due to GPU reset!
amdgpu: GPU reset(1) succeeded!
gnome-shell: X connection to :0 broken (explicit kill or server shutdown).
Representative 6.12.107 native-service failure
================================================
amdgpu: ring vce0 timeout, signaled seq=127, emitted seq=128
amdgpu: Process information: process rustdesk pid 4670 thread rustdesk:cs0 pid 21229
amdgpu: GPU reset begin!
amdgpu: failed to suspend display audio
amdgpu: GPU reset(1) succeeded!
Reproducer
==========
1. Boot the affected Debian kernel with the RX 480 bound to amdgpu.
2. Start the normal GNOME/GDM X11 graphical session.
3. Use RustDesk 1.4.9 through its native package/system service to establish
an active remote-control session.
4. Interact normally with the desktop while monitoring the kernel journal.
5. Within roughly 15-30 seconds in the controlled failing runs, the remote
session freezes and the vce0 timeout/reset sequence appears.
I did not intentionally reproduce the reset again while collecting this
reportbug metadata under 6.12.107.
Workaround
==========
Persistent GRUB selection currently boots 6.12.101, which restores stable
RustDesk operation. No kernel packages are held, so future candidate kernels
can continue to be installed and explicitly tested.
SSH survives the GPU-reset event, so this should not be characterized as a
full-system crash. It is nevertheless a repeatable regression capable of
resetting the GPU and, on 6.12.105, terminating the graphical session.
The reportbug-generated kernel and package information follows.