Re: Bug#1118349: dpm broken on Radeon HD 8570D

[Salvatore Bonaccorso <carnil@debian.org>]

Control: tags -1 + moreinfo

Hi all,

On Sat, Nov 22, 2025 at 07:40:33PM +0200, Roman Savochenko wrote:
> Hi, Uwe Kleine-König
> 
> 22.11.25 19:22, Uwe Kleine-König:
> > On Fri, Nov 21, 2025 at 11:11:39AM +0200, Roman Savochenko wrote:
> > > 21.11.25 10:35, Uwe Kleine-König:
> > > > On Thu, Nov 20, 2025 at 06:45:48PM +0200, Roman Savochenko wrote:
> > > > > 20.11.25 10:38, Uwe Kleine-König:
> > > > > > On Wed, Nov 19, 2025 at 08:23:31PM +0200, Roman Savochenko wrote:
> > > > > > > 19.11.25 19:05, Uwe Kleine-König:
> > > > > > > > On Wed, Nov 12, 2025 at 06:19:07PM +0200, Roman Savochenko wrote:
> > > > > > > > > 12.11.25 17:03, Christian König:
> > > > > > > > > > On 11/12/25 15:28, Roman Savochenko wrote:
> > > > > > > > > > > 12.11.25 13:14, Uwe Kleine-König:
> > > > > OK, and what do you want from me?
> > > > Quoting an earlier mail in that thread:
> > > > 
> > > > 	Can you try which Debian kernel was the last one working fine
> > > > 	respective the first being broken in this regard? You can find
> > > > 	all kernels onhttps://snapshot.debian.org/. Please ask if it's
> > > > 	unclear how to do that.
> > > I have told that as the kernel in Debian 11.
> > Is that the last working or the first broken?
> > 
> > The last kernel in Debian 11 (i.e. buster) is 5.10.218-1. Or do you mean
> > the last in buster-security which would be 5.10.244-1? Or do you mean
> > the one that Debian 11.0 was released with, that would be 5.10.46-4 (I
> > think)?
> > 
> > The kernels before and after that are depending on what you meant above
> > 5.10.216-1 or 5.10.237-1 or 5.10.46-3 and 5.10.221-1 or
> > 5.13.9-1~exp1 or 5.10.46-5. Which one do you mean?
> > 
> > The gist to take away here is: Don't specify kernel versions as "the one
> > in Debian 11" or "kernel 5" but use the proper kernel (package) version.
> > Everything else is too fuzzy for me to work with.
> 
> And what that about when I have said that precisely???
> 
> > Kernel 5 what? E.g. which concrete version number? (output of uname -a).
> user@debian:~$ cat /proc/version
> 
> Linux version 5.10.0-32-amd64 (debian-kernel@lists.debian.org) (gcc-10
> (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2)
> #1 SMP Debian 5.10.223-1 (2024-08-10)
> 
> > > > > Must I say you the exact commit or what,
> > > > > or you are waiting I must recompile all kernels with 294457 commits?
> > > > > 
> > > > > I say you in what way the problem related through the stable kernels in
> > > > > Debian releases and that is exactly assigned to the major versions of the
> > > > > Linux kernel, even for broken v5.19 which can include backports from 6!
> > > > Yeah, you keep talking about Linux 3, 4, 5 and 6. These categories cover
> > > > several years of development each and thus are not helpful to locate the
> > > > change that broke your setup. Unless it is really 5.19 that was good and
> > > > 6.0 that is bad which limits the amount of changes from:
> > > I keep talking that only for understanding the problem depth and not for
> > > fixing that in 4 kernels!
> > > 
> > > That is, there can be simpler to apply that workaround.
> > > 
> > > > . This is still a lot and we might ask you to do more tests to further
> > > > limit the set of candidate commits that are broken on your end.
> > > OK, ask.
> > That depends on the answers for the questions I already asked and that
> > are still not answered in a way that I can ask the followup questions.
> 
> Reread the stream then!
> 
> > > > > > Can you please confirm that 5.19.x (e.g. a kernel package from
> > > > > > https://snapshot.debian.org/package/linux/5.19.11-1/) works fine and
> > > > > > 6.0.x (e.g.https://snapshot.debian.org/package/linux/6.0.12-1/)
> > > > > > doesn't? (Or a similar statement with other consecutive mainline
> > > > > > versions.)
> > > > > 5.19.0 has this problem in view of hanging.
> > > > You lost me here. What is "problem in view of hanging"? Are we talking
> > > > about more than one problem? Or different variants of the same problem?
> > > We talk about different variants, and the hanging I saw also on one 6 kernel
> > > just after installing Debian 13 and that is why #1118349 I opened about the
> > > hanging but not rebooting in the initial report #879992.
> > Here is our language problem again. I fail to parse that sentence.
> 
> Reread the first message then:
> 
> >  From Debian 12 (any Linux kernel 6) and now in Debian 13 it is obligatory
> > reproducing not as restarting but freezing with black screen and on any kernel
> > 6 version (also 6.16.3+deb13-amd64).
> > > To help for other with same hardware, since I can fix that for myself if I
> > > need.
> > ??
> ??
> > > > For now your problem report isn't in a form that I can act upon. So it's in your interest to provide the
> > > > information that I ask for. If you don't want to do that, that's fine,
> > > > and I won't have sleepless nights about it. The likely outcome is that
> > > > the problem isn't addressed.
> > > Whether I don't provide you all information beyond "get my hand in the
> > > dirty"? :)
> > ??
> ??
> > > > Parts of the misunderstanding here might also be a language barrier. So
> > > > maybe try to get some help in the kernel community that speaks your
> > > > native tongue.
> > > So, English isn't native one for you? :)
> > Right, and I doubt it's yours either. Or you would be the first native
> > English speaker in my career that I fail to understand when
> > communicating about Linux topics. (The only other explanations for that
> > I can come up with are a) you suffer from dyslexia; or b) you write
> > glibberish on purpose to annoy.)
> > 
> > PSA: This is my last mail to you for this bug until you come up with a
> > statement like:
> > 
> > 	I tested Debian kernel image package version a.b.c-d and its
> > 	broken with the following symptoms: [....]. The kernel image
> > 	that occurs in the list on
> > 	https://snapshot.debian.org/package/linux/ directly after that
> > 	(i.e. version e.f.g-h) doesn't show these symptoms.
> 
> As if I need your messages with your dyslexia... :)

The discussion here is derailing. Roman, if we want to have the issue
fixed I support Uwe statement thate we have you, with the affected
hardware, bisect the upstream change to isolate the fixing commit. 

Here are the steps which roughly are involved. Confirm a upstream
version which does not expose the problem. Ideally first though by
using the snapshot.debian.org service as pointed out narrow down more
closely the upstream range where things change. Once you have a set of
kernel which are close enough start bisecting the change. Let's take
te following hypotetical versions, working kernel v6.11 and not
working kernel is v6.12.

|     git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
|     cd linux-stable
|     git checkout v6.11
|     cp /boot/config-$(uname -r) .config
|     yes '' | make localmodconfig
|     make savedefconfig
|     mv defconfig arch/x86/configs/my_defconfig
| 
|     # test 6.11 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.12 to ensure this is "bad"
|     git checkout v6.12
|     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
|     git bisect good v6.11
|     git bisect bad v6.12
| 
| 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 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.

I'm closing this bug along. If you can provide the above version
please respond to this message with the required information and a
control message to reopen the bugreport.

This is how you can help to resolve the issue in my point of view.

Regards,
Salvatore