Salvatore,
I am following up on the bisection results I previously submitted for
Debian bug #1146343.
After that report, the previously heavily qualified immediate-parent
custom kernel, commit
`fa9624ad4d6d4b25e448dbc550ddc69e6f849640`(`6.12.104-hnv2-b1146343-gfa9624ad4d6d`),
showed a GPU-related operational failure during normal use while a
RustDesk-related problem was observed.
The preserved journal does **not**reproduce the original bisection's
characteristic lead signature. There is no `ring vce0 timeout`and no
`amdgpu_job_timedout`. Instead, the event begins with GPU VM protection
faults attributed to `totem`, followed by a `ring gfx timeout`attributed
to Xorg, GPU reset, and VRAM loss. The VCE block appears only as a
failed suspend step during recovery.
Representative sequence:
```text
amdgpu: GPU fault detected ... for process totem
amdgpu: VM fault ...
amdgpu: ring gfx timeout ...
amdgpu: GPU reset begin!
[drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP
block <vce_v3_0> failed -22
amdgpu: GPU reset succeeded, trying to resume
[drm] VRAM is lost due to GPU reset!
```
I therefore classify this later event as **DIFFERENT-SIGNATURE**, not as
a reproduction of the RustDesk H.264 VAAPI `ring vce0 timeout`used to
classify the BAD bisection kernels. It is a separate operational
observation and does not by itself invalidate the mechanical first-bad
result. I am not claiming that RustDesk, Totem, or the bisected change
caused this event.
For operational safety I have nevertheless withdrawn `fa9624...`as the
preferred default. Exact stable `v6.12.103`, commit
`25c09b42358e73e1476e517b296edb6344f2e4bd`, remains directly qualified
GOOD and is now the work-box default. After promotion it booted normally
twice and completed a further 21m06s real RustDesk H.264 VAAPI canary
with multiple connections/reconnects, 126/126 clean samples, and no VM
fault, VCE/GFX timeout, GPU reset, VRAM loss, or
`amdgpu_job_timedout`line. Manuel confirmed that the visuals were stable
throughout, with no freeze, disconnect anomaly, or visible degradation
attributable to work-box.
Given that the full v6.12.105 tree remained BAD after reverting the
mechanically first-bad commit, and that a later operational event on its
immediate GOOD parent showed a distinct AMDGPU gfx/VM-reset failure
path, it is possible that more than one nearby stable-tree change
contributes to the broader instability seen in the later kernels. I have
not isolated or proven such an interaction.
The original interpretation remains conservative:
-mechanical first bad: `52566c150cadb1a17df840dd25862a61dcf84bed`;
-immediate parent: `fa9624ad4d6d4b25e448dbc550ddc69e6f849640`, strongly
qualified GOOD in the bounded bisection trials but now withdrawn as the
operational default because of this distinct later event;
-v6.12.105 with only `52566c...`reverted remained BAD;
-the mechanical boundary is established, while single-commit causal
sufficiency is not established.
I can provide the complete affected-boot journal and the exact
`.103`post-promotion evidence if useful.
Regards,
Manuel
On 9/1/2026 4:00 PM, Salvatore Bonaccorso wrote:
Hi Manuel, all
On Tue, Sep 01, 2026 at 06:52:55AM +0200, Salvatore Bonaccorso wrote:
Control: tags -1 + moreinfo
Hi,
On Mon, Aug 31, 2026 at 10:41:47AM -0500, Manuel R. Buffa wrote:
Package: src:linux
Version: 6.12.107-1
Severity: important
X-Debbugs-Cc:[email protected]
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.
[...]
As you can reproduce your issue reliably, please bisect the changes
between 6.12.101 and 6.12.105 to identify the breaking commit. That
given we can have a look if it is a known regression already or needs
to be reported upstream yet.
Let me know if you need instructions for the bisecting steps!
Manuel asked off-bug about the instructions, so here we go. To bisect
between 6.12.101 and 6.12.105 proceed as follows (once you have the
my_config, compilation could be as well on a more powerful machine).
git clone --single-branch -b
linux-6.12.yhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
cd linux-stable
git checkout v6.12.101
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 6.12.101 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does not exist
# test 6.12.105 to ensure this is "bad"
git checkout v6.12.105
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem exists
With that confirmed, the bisection can start:
git bisect start
git bisect good v6.12.101
git bisect bad v6.12.105
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Regards,
Salvatore
Debian BTS #1146343 follow-up — exact v6.12.103 operational proof
Source/tag: stable v6.12.103
Commit: 25c09b42358e73e1476e517b296edb6344f2e4bd
Installed release: 6.12.103-hnv2-b1146343-tag103
GRUB default: Advanced options for Debian GNU/Linux>Debian GNU/Linux, with
Linux 6.12.103-hnv2-b1146343-tag103
GRUB selection model: explicit deterministic default; no one-shot selection or
automatic fallback
Two ordinary default boots:
1. e159ad82-d582-42e1-9c51-588f1d86a2ed
2. 1de45e5a-c8ca-409b-b142-6e9c591eff2e (current at closeout)
Both boots verified the exact release, RX480/Polaris10 bound to amdgpu, VCE
initialization, active SSH/RustDesk/GDM, system state running, taint 0, zero
failed units, established mounts, and no characteristic GPU failure line.
Post-promotion RustDesk canary:
- Window: 2026-09-06 10:41:06 to 11:02:12 CDT (21m06s).
- Real hardware encoder: h264_vaapi, 1440x900, quality 0.5.
- Multiple connections/reconnects and fresh encoders observed.
- Samples: 126/126 clean.
- Every sample retained the exact kernel/boot identity, active
SSH/RustDesk/GDM, taint 0, and zero monitored GPU-failure lines.
- Complete candidate-boot journal contained no VM fault, ring vce0/gfx timeout,
GPU reset, VRAM loss, amdgpu_job_timedout, or blocked/hung-task signature.
- Manuel confirmed stable visuals throughout, with no freeze, disconnect
anomaly, or visible degradation attributable to work-box.
Operational result: exact v6.12.103 remains bounded GOOD and is now the
deterministic work-box default.
Debian BTS #1146343 follow-up — later fa9624 operational event
Classification: DIFFERENT-SIGNATURE
Affected kernel: 6.12.104-hnv2-b1146343-gfa9624ad4d6d
Commit: fa9624ad4d6d4b25e448dbc550ddc69e6f849640
Boot ID: accfa0ed-60ae-4669-8e7c-b931600d5630
Focused event sequence (2026-09-06 CDT):
2026-09-06T10:26:48.435599-05:00 work-box dbus-daemon[2488]: Successfully
activated service 'org.gnome.Totem'
2026-09-06T10:26:50.911640-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
GPU fault detected: 147 0x00024402
2026-09-06T10:26:50.917102-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
for process totem pid 515864 thread totem:cs0 pid 515912
2026-09-06T10:26:50.918440-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
VM fault (0x02, vmid 6, pasid 229) at page 3072, write from 'TC5' (0x54433500)
(68)
2026-09-06T10:26:50.918822-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
GPU fault detected: 147 0x00004402
2026-09-06T10:26:50.919210-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
for process totem pid 515864 thread totem:cs0 pid 515912
2026-09-06T10:26:50.922812-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
VM fault (0x02, vmid 6, pasid 229) at page 3072, read from 'TC5' (0x54433500)
(68)
2026-09-06T10:27:01.159590-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
ring gfx timeout, signaled seq=576881, emitted seq=576883
2026-09-06T10:27:01.160102-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
Process information: process Xorg pid 2601 thread Xorg:cs0 pid 3022
2026-09-06T10:27:01.160473-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
GPU reset begin!
2026-09-06T10:27:05.279604-05:00 work-box kernel:
[drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block
<vce_v3_0> failed -22
2026-09-06T10:27:05.927614-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
GPU reset succeeded, trying to resume
2026-09-06T10:27:05.929513-05:00 work-box kernel: [drm] VRAM is lost due to GPU
reset!
2026-09-06T10:27:06.239717-05:00 work-box kernel: amdgpu 0000:01:00.0: amdgpu:
GPU reset(1) succeeded!
Complete-boot signature counts:
ring_vce0_timeout 0
ring_gfx_timeout 1
amdgpu_job_timedout 0
gpu_reset 4
vram_loss 1
device_loss 0
blocked_task 0
vm_or_gpu_fault 4
Interpretation: this later event contains a real AMDGPU reset and VRAM loss,
but its lead fault/ring/process path differs from the RustDesk H.264 VAAPI
ring-vce0 timeout signature used for the BAD bisection classifications. It is
not asserted to be the same bug.
