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,
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.yhttps://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
