Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #92885 > unrolled thread

Bug#1138755: Subject: amdgpu: RX 640 hangs right after VCE initialization on kernel 6.12 (i5-11400F, no iGPU)

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1138755: Subject: amdgpu: RX 640 hangs right after VCE initialization on kernel 6.12 (i5-11400F, no iGPU) Salvatore Bonaccorso <carnil@debian.org> - 2026-06-03 17:00 +0200
    Bug#1138755: Subject: amdgpu: RX 640 hangs right after VCE initialization on kernel 6.12 (i5-11400F, no iGPU) Salvatore Bonaccorso <carnil@debian.org> - 2026-06-07 17:00 +0200

#92885 — Bug#1138755: Subject: amdgpu: RX 640 hangs right after VCE initialization on kernel 6.12 (i5-11400F, no iGPU)

Hi,

On Wed, Jun 03, 2026 at 05:21:40PM +0800, Yike Guo wrote:
> Package: src:linux
> Version: 6.12.74+deb13+1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading to the 6.12.88 kernel on Debian 13 (Trixie), the system
> completely hangs during the boot process, right before the GDM login screen
> should appear.
> 
> Hardware Configuration:
> - CPU: Intel Core i5-11400F (Rocket Lake, no integrated graphics)
> - GPU: AMD Radeon RX 640 (Polaris12 / Lexa architecture, standalone PCIe)
> 
> Observed Behavior:
> By removing 'quiet' and 'splash' from the GRUB kernel parameters, I
> monitored the boot log. The kernel initialization proceeds normally until
> the amdgpu driver finishes initializing the Video Codec Engine.
> 
> The last visible log line on the screen is exactly:
> [    3.384886] [drm] VCE enabled in VM mode
> 
> Immediately after this line, the system completely freezes during the Kernel
> Mode Setting (KMS) transition / DPI change. The display output lockups, but
> 'Ctrl + Alt + Delete' can still successfully trigger a soft reboot within a
> few seconds, after which the soft reboot will no longer be triggered.
> 
> Steps to Reproduce:
> 1. Boot into kernel 6.12.90(or 88)+deb13+1-amd64 on the specified hardware.
> 2. The screen hangs forever right after the VCE initialization line.
> 
> Note: The system boots and works perfectly under the older kernel (up to
> 6.12.74). I suspect a regression in the amdgpu display core (DC) or
> scatter-gather display handling on platforms without an iGPU.
> 
> I have attached a photo of the final frame of the boot log before the hang
> for your reference.

Thanks for your report. Two questions.

Is this problem reproducible with the version 7.0.10-1 available in
testing (it is available as well in trixie-backports).

Given you can state when the problem is hit, can you bisect the
changes between 6.12.74 and 6.12.88? The procedure would be as
follows, involving compiling and testing a couple of kernels:

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.74
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.74 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it successfully boots

    # test 6.12.88 to ensure this is "bad"
    git checkout v6.12.88
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it fails to boot as described by you

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v6.12.74
    git bisect bad v6.12.88

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, try to boot and 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.

Thanks already,

Regards,
Salvatore

[toc] | [next] | [standalone]

#92913

Hi Yike,

On Sun, Jun 07, 2026 at 03:37:00PM +0800, Yike Guo wrote:
> Dear Maintainer,
> 
> Before the bisecting process, I first attempt to install the newest
> backported kernal 7.0.10-1(with debian suffix) and reboot, unfortunately it
> still doesn't work.

Ok, bad but then we know which route to go.

> And I didn't receive your reply from my mailbox, I only see your reply in
> the Debian bug tracing system.

Hmm, can you check if it is in Spam?

> I will fill this issue in the freedesktop's gitlab page as soon as possible.

Thank you. Can you loop back here the upstream issue reference so we
can properly track the status?

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web