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.

Hi,

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

Dear Maintainer,

By following you instructions, I have located the first bad commit, here
is the bisect log:

$ git bisect log
git bisect start
# 状态：正在等待好的和坏的提交 (waiting for good and bad commit)
# good: [444b39ef6108313e8452010b22aaba588e8fb92b] Linux 6.12.74
git bisect good 444b39ef6108313e8452010b22aaba588e8fb92b
# 状态：正在等待坏的提交，已知 1 个好的提交 (waiting for bad commit, 1 good
commit known)
# bad: [bf89928ffeb731c623a15ee7327261131a80ddcb] Linux 6.12.86
git bisect bad bf89928ffeb731c623a15ee7327261131a80ddcb
# good: [276aef0fd2b92f41b920ac891c72cadeee957934] usb: class: cdc-wdm:
fix reordering issue in read code path
git bisect good 276aef0fd2b92f41b920ac891c72cadeee957934
# good: [673bbd36cba21d10a10f0932f479df7468e26fbb] netfilter: x_tables:
ensure names are nul-terminated
git bisect good 673bbd36cba21d10a10f0932f479df7468e26fbb
# bad: [796e0cac058252d0ad34ebe288e6f7979b5fc9b2] nfc: llcp: add missing
return after LLCP_CLOSED checks
git bisect bad 796e0cac058252d0ad34ebe288e6f7979b5fc9b2
# bad: [269d80981a5c79246fd5594b3603cdda0d0205bb] selftests/bpf: Test
cross-sign 64bits range refinement
git bisect bad 269d80981a5c79246fd5594b3603cdda0d0205bb
# good: [42d4e0d4f12cd23fbfc694929ff80aa361abb0b0] iio: imu: bmi160:
Remove potential undefined behavior in bmi160_config_pin()
git bisect good 42d4e0d4f12cd23fbfc694929ff80aa361abb0b0
# good: [94d4fab1dd9e64f45449bcc7d6a5acf796b13015] USB: dummy-hcd: Fix
interrupt synchronization error
git bisect good 94d4fab1dd9e64f45449bcc7d6a5acf796b13015
# good: [7cbd69aaa507b1245240a28022bf5da0f07c68d9] scsi: target:
tcm_loop: Drain commands in target_reset handler
git bisect good 7cbd69aaa507b1245240a28022bf5da0f07c68d9
# good: [2145a80f47cd5bc57099297173aa1bce1b915a86] x86/CPU/AMD: Add
additional fixed RDSEED microcode revisions
git bisect good 2145a80f47cd5bc57099297173aa1bce1b915a86
# bad: [85229e17e8d7e384e8ba603f6942ebff5aaedcce] drm/amd/display: Fix
DCE 6.0 and 6.4 PLL programming.
git bisect bad 85229e17e8d7e384e8ba603f6942ebff5aaedcce
# bad: [1f9b3e72fd7da18c94678877add79d7741a0a0d7] drm/amd/amdgpu:
disable ASPM in some situations
git bisect bad 1f9b3e72fd7da18c94678877add79d7741a0a0d7
# bad: [8f187036a3e656b54493cdd46f50bd25bee9dc00] drm/amd/amdgpu:
decouple ASPM with pcie dpm
git bisect bad 8f187036a3e656b54493cdd46f50bd25bee9dc00
# first bad commit: [8f187036a3e656b54493cdd46f50bd25bee9dc00]
drm/amd/amdgpu: decouple ASPM with pcie dpm

I think it should be an amd graphic card issue, and I hope this will
help you resolve this bug.

Best Regards,
Yike

Hi,

Thanks for doing that and finding the commit. Now that change was
backported from 6.16-rc1 change to the 6.12.y series. Can you please
check if the issue is still present using the 7.0.10-1 kernel?

If yes, then can you please fill an issue in
https://gitlab.freedesktop.org/drm/amd/-/work_items

If not we should likely forward the issue to the stable and
regressions list (including the amdgpu maintainers and involved people
in the change).

But can you please first test 7.0.10-1 to determine if the issue is
present as well there?

Regards,
Salvatore

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.

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

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

Thanks for your help,

Best Regards,
Yike

Hi Yike,

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

Hmm, can you check if it is in Spam?

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

Regards,
Salvatore

You may also want to pull firmware-amd-graphics from backports as well
if you didn't already.

Still not working, thus it may not be a firmware issue.

Dear Maintainers,

I have opened an issue in the freedesktop's gitlab page following your
request, and its reference link is
_https://gitlab.freedesktop.org/drm/amd/-/work_items/5370_.
I have reinstall the newest kernel from backports and the corresponding
newest firmware-amd-graphics and it still doesn't work.
I have no idea what's going on, I have double check the spam/junk box
and it appears the email is not there. Anyway, I will always frequently
check the bug tracing page in case I miss some response.

Best regards,
Yike