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,
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
