Bug#1111184: linux: Kernel panic on boot with amdgpu driver

[Salvatore Bonaccorso <carnil@debian.org>]

Control: tags -1 + trixie
Control: fixed -1 6.16.1-1~exp1
Hi,

On Wed, Aug 20, 2025 at 05:08:05PM +0300, Руслан Семченко wrote:
> Hello, Uwe,
> Thank you for your response and for pointing out the confusion in my
> previous message. I apologize for the unclear report. I performed two
> separate tests as you requested, and I will provide the full logs for
> each.
> Test 1: Stable Kernel (6.12.41+deb13-amd64) This is the kernel that
> comes with Debian 13 (Trixie). The system fails to boot with a kernel
> panic related to the amdgpu driver, as initially reported. The full
> dmesg log for this test is attached.
> 
> Test 2: Experimental Kernel (6.16-amd64) This kernel was installed
> from the 'experimental' repository. The system boots normally, and the
> kernel panic does not occur. The full dmesg log for the successful
> boot is also attached.
> This indicates that the issue appears to be resolved in the 6.16
> kernel. I hope these complete logs help.

Thank you that is already very helpful to asess this for upper
versions, i.e. we can mark the metadata accordingly.

Would you be in the position to try to bisect the upstream changes and
see if we can isolate which change upstream did fix the issue? A start
would be to first "bisect" the Debian kernel images version, but is is
not a straighforward line as we know 6.12.41-1 is problematic, and
6.16.1-1~exp1 is good.

So we have the following candidates uploaded later on to experimental:

	6.16.1-1~exp1
	6.16-1~exp1
	6.16~rc7-1~exp1
	6.15.6-1~exp1
	6.15.5-1~exp1
	6.15.4-1~exp1
	6.15.3-1~exp1
	6.15.2-1~exp1
	6.15.1-1~exp1
	6.15-1~exp1
	6.15~rc7-1~exp1
	6.14.6-1~exp1
	6.14.5-1~exp1
	6.14.3-1~exp1
	6.13.11-1~exp1
	6.13.10-1~exp1
	6.13.9-1~exp1
	6.13.8-1~exp1
	6.13.7-1~exp1
	6.13.6-1~exp1
	6.13.5-1~exp1
	6.13.4-1~exp1
	6.13.3-1~exp1
	6.13.2-1~exp1
	6.13~rc7-1~exp1
	6.13~rc6-1~exp1

You could start by fetching 6.13~rc6-1~exp1 and see if that is bad as
well, before bisecting though check the major version bumps, so
6.14.3-1~exp1, 6.15~rc7-1~exp1. If we have found the two major
versions which are one one side good and on the other bad, we have
IMHO a stating point to bisect now the upstream versions.

You can get the Debian packages for the (signed) image via the
snapshots service:
https://snapshot.debian.org/package/linux-signed-amd64/

(Remember to remove after the experiment old images again).

Once we have the two major upstream version on one side bad and on the
other good, we could start bisection, roughly it should go the
following way. Say hypotetical you foun 6.13~rc6-1~exp1 as bad
6.14.3-1~exp1 as good, then 


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

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

        # test 6.13~rc6 to ensure this is "bad"
        git checkout v6.13-rc6
        make my_defconfig
        make -j $(nproc) bindeb-pkg
        ... install the resulting .deb package and confirm it fails to boot / problem exists

With that confirmed, the bisection can start:
	git bisect start --term-new=fixed --term-old=broken
	git bisect fixed v6.14.3
	git bisect broken v6.13-rc6

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 / verify if problem exists

and if the problem is hit run:
 
        git bisect broken

and if the problem doesn't trigger run:
 
        git bisect fixed

. 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 'fixed'
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.

Hope this helps us to identify more about the issue.

Regards,
Salvatore