dpm broken on Radeon HD 8570D

dpm broken on Radeon HD 8570D

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

Control: forwarded -1 https://lore.kernel.org/amd-gfx/epyf7tdz3azb3fflb6rwuhax7mpccmqlsmzqqe2pcm7mxrdur4@zpx2uo5pvoqs

Hello,

A Debian user (Roman Savochenko, on Cc:) reports issues (freezing with
black screen) with a Radeon HD 8570D graphics adapter. When passing
`radeon.dpm=0` on the kernel commandline the problems are gone.

Is it a sensible quirk to let dpm default to 0 with that hardware? Or
does the behaviour depend on (e.g.) the actual monitor in use?

Or is there a bug to fix? If so, do you have a hint what to do, is there
more information needed from the affected system?

The full bug history is available at https://bugs.debian.org/1118349,
which also contains some hardware information.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: dpm broken on Radeon HD 8570D

[Deucher, Alexander]

[Public]

> -----Original Message-----
> From: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> Sent: Monday, November 10, 2025 10:27 AM
> To: Deucher, Alexander <Alexander.Deucher@amd.com>; Koenig, Christian
> <Christian.Koenig@amd.com>
> Cc: amd-gfx@lists.freedesktop.org; 1118349@bugs.debian.org; Roman
> Savochenko <roman@oscada.org>
> Subject: dpm broken on Radeon HD 8570D
>
> Control: forwarded -1 https://lore.kernel.org/amd-
> gfx/epyf7tdz3azb3fflb6rwuhax7mpccmqlsmzqqe2pcm7mxrdur4@zpx2uo5p
> voqs
>
> Hello,
>
> A Debian user (Roman Savochenko, on Cc:) reports issues (freezing with black
> screen) with a Radeon HD 8570D graphics adapter. When passing
> `radeon.dpm=0` on the kernel commandline the problems are gone.
>
> Is it a sensible quirk to let dpm default to 0 with that hardware? Or does the
> behaviour depend on (e.g.) the actual monitor in use?

DPM worked fine on this hardware.  I'm not familiar with any general issues with it.  It may be system specific.

>
> Or is there a bug to fix? If so, do you have a hint what to do, is there more
> information needed from the affected system?
>
> The full bug history is available at https://bugs.debian.org/1118349, which
> also contains some hardware information.


If this is a regression can you bisect?

Thanks,

Alex

>
> Best regards
> Uwe

Re: dpm broken on Radeon HD 8570D

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

Hello

10.11.25 18:35, Deucher, Alexander:
>> Is it a sensible quirk to let dpm default to 0 with that hardware? Or does the
>> behaviour depend on (e.g.) the actual monitor in use?
> DPM worked fine on this hardware.  I'm not familiar with any general issues with it.  It may be system specific.

On my hardware that doesn't work and there is no specific.

And I have recorded a video with reproduction this problem.

Now just I set "radeon.dpm=1", I got immediately restart with disabling 
USB, so I have needed to restart for successful download with 
"radeon.dpm=0".

[-- Attachment #2: MAH03529.mp4 --]
[-- Type: video/mp4, Size: 5960449 bytes --]

[-- Attachment #3: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

Control: tag -1 + moreinfo

Hello Roman,

On Mon, Nov 10, 2025 at 10:00:01PM +0200, Roman Savochenko wrote:
> 10.11.25 18:35, Deucher, Alexander:
> > > Is it a sensible quirk to let dpm default to 0 with that hardware? Or does the
> > > behaviour depend on (e.g.) the actual monitor in use?
> > DPM worked fine on this hardware.  I'm not familiar with any general issues with it.  It may be system specific.
> 
> On my hardware that doesn't work and there is no specific.
> 
> Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
> so I have needed to restart for successful download with "radeon.dpm=0".

Can you try a different monitor?

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 on
https://snapshot.debian.org/. Please ask if it's unclear how to do that.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Roman Savochenko]

[-- Attachment #1.1: Type: text/plain, Size: 851 bytes --]

12.11.25 13:14, Uwe Kleine-König:
>> On my hardware that doesn't work and there is no specific.
>>
>> Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
>> so I have needed to restart for successful download with "radeon.dpm=0".
> Can you try a different monitor?

I have only one, connected through DVI, and there is no problem on Linux 
Kernel 5.

> 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 on
> https://snapshot.debian.org/. Please ask if it's unclear how to do that.

I can try all kernels in Debian starting 7 and finishing 13, but I have 
traced that before and the problem reproduction started from Debian 9, 
terminated on Debian 11 and renewed on Debian 12.

Say which Debian version you need to try.

Regards, Roman

[-- Attachment #1.2: Type: text/html, Size: 1628 bytes --]

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Christian König]

On 11/12/25 15:28, Roman Savochenko wrote:
> 12.11.25 13:14, Uwe Kleine-König:
>>> On my hardware that doesn't work and there is no specific.
>>>
>>> Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
>>> so I have needed to restart for successful download with "radeon.dpm=0".
>> Can you try a different monitor?
> 
> I have only one, connected through DVI, and there is no problem on Linux Kernel 5.

Kernel 5 what? E.g. which concrete version number? (output of uname -a).

> 
>> 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 on
>> https://snapshot.debian.org/. Please ask if it's unclear how to do that.
> 
> I can try all kernels in Debian starting 7 and finishing 13, but I have traced that before and the problem reproduction started from Debian 9, terminated on Debian 11 and renewed on Debian 12.

How keen are you to compile the kernel yourself? That is usually relatively easy to do and git has a bisect command which allows you to pinpoint which kernel patch actually changes something.

Regards,
Christian.

> 
> Say which Debian version you need to try.
> 
> Regards, Roman
> 

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

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

12.11.25 13:14, Uwe Kleine-König:
>> Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
>> so I have needed to restart for successful download with "radeon.dpm=0".
> Can you try a different monitor?

The problem is reproducible on any monitor and video-output due to I 
tried the same through VGA and TV through HDMI.

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

Hello,

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:
> > > > > On my hardware that doesn't work and there is no specific.
> > > > > 
> > > > > Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
> > > > > so I have needed to restart for successful download with "radeon.dpm=0".
> > > > Can you try a different monitor?
> > > I have only one, connected through DVI, and there is no problem on Linux Kernel 5.
> > 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)
> 
> > > > 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 on
> > > > https://snapshot.debian.org/. Please ask if it's unclear how to do that.
> > > I can try all kernels in Debian starting 7 and finishing 13, but I have traced that before and the problem reproduction started from Debian 9, terminated on Debian 11 and renewed on Debian 12.

Not sure I follow. Does that mean that Debian 9, Debian 10, Debian 12
and Debian 13 show the symptom and Debian 11 doesn't?

In that case the interesting interval is 5.10 .. 6.1. If you could
pinpoint the oldest kernel image package that shows the symptoms that
would be great.

> > How keen are you to compile the kernel yourself? That is usually relatively easy to do and git has a bisect command which allows you to pinpoint which kernel patch actually changes something.

For the typical Linux user compiling their own kernel is a big hurdle,
so usually we (= Debian kernel team) ask for bisecting using
distribution kernel packages first which tends to be a bit easier.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

19.11.25 19:05, Uwe Kleine-König:
> In that case the interesting interval is 5.10 .. 6.1. If you could
> pinpoint the oldest kernel image package that shows the symptoms that
> would be great.

The oldest Linux kernel 6 is only one on the actual Debian 12 
installation on this PC:

roman@home:~$ cat /proc/version
Linux version 6.1.0-33-amd64 (debian-kernel@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.133-1 (2025-04-10)

And the problem is actual here since I have loaded from the kernel only 
with "radeon.dpm=0":

roman@home:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.1.0-33-amd64 
root=UUID=dd0275fe-934a-4742-8f89-0bc5c0357dad ro radeon.dpm=0 quiet splash

Regards, Roman

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]

Hello Roman,

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:
> > > > > > > On my hardware that doesn't work and there is no specific.
> > > > > > > 
> > > > > > > Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
> > > > > > > so I have needed to restart for successful download with "radeon.dpm=0".
> > > > > > Can you try a different monitor?
> > > > > I have only one, connected through DVI, and there is no problem on Linux Kernel 5.
> > > > 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)
> > > 
> > > > > > 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 on
> > > > > > https://snapshot.debian.org/. Please ask if it's unclear how to do that.
> > > > > I can try all kernels in Debian starting 7 and finishing 13, but I have traced that before and the problem reproduction started from Debian 9, terminated on Debian 11 and renewed on Debian 12.
> > Not sure I follow. Does that mean that Debian 9, Debian 10, Debian 12
> > and Debian 13 show the symptom and Debian 11 doesn't?
> 
> Yes, and in kernels that is 4, 6 show the symptom and 3, 5 don't.

I think this statement isn't helpful unless you're saying that Linux
5.19 was good and 6.0 was bad. Kernel versions started with 5 between
2019-03-03 and 2022-07-31, not taking stable releases into account. And
there are 294457 commits in that range
(`git rev-list v5.0..v5.19 | wc -l`). So "kernel 5" and "kernel 6" is a
bit too fuzzy to work with.

> > In that case the interesting interval is 5.10 .. 6.1. If you could
> > pinpoint the oldest kernel image package that shows the symptoms that
> > would be great.
> 
> I can show only the last official kernels in the correspond Debian
> distributive due to their applied in the Live Disks!
> 
> That is, I have recorded a video when the problem reproduction started, that
> is Debian 9 with kernel 4.9.

Nobody in the OSS community is interested in 4.9 any more. This kernel
version is EOL since January 2023.

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.)

Note that even that might not be enough to spot the problem and you
might have to get your hands dirty then and compile development kernels
and test them.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 5917 bytes --]

Hello Roman,

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:
> > > > > > > > > On my hardware that doesn't work and there is no specific.
> > > > > > > > > 
> > > > > > > > > Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
> > > > > > > > > so I have needed to restart for successful download with "radeon.dpm=0".
> > > > > > > > Can you try a different monitor?
> > > > > > > I have only one, connected through DVI, and there is no problem on Linux Kernel 5.
> > > > > > 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)
> > > > > 
> > > > > > > > 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 on
> > > > > > > > https://snapshot.debian.org/. Please ask if it's unclear how to do that.
> > > > > > > I can try all kernels in Debian starting 7 and finishing 13, but I have traced that before and the problem reproduction started from Debian 9, terminated on Debian 11 and renewed on Debian 12.
> > > > Not sure I follow. Does that mean that Debian 9, Debian 10, Debian 12
> > > > and Debian 13 show the symptom and Debian 11 doesn't?
> > > Yes, and in kernels that is 4, 6 show the symptom and 3, 5 don't.
> > I think this statement isn't helpful unless you're saying that Linux
> > 5.19 was good and 6.0 was bad. Kernel versions started with 5 between
> > 2019-03-03 and 2022-07-31, not taking stable releases into account. And
> > there are 294457 commits in that range
> > (`git rev-list v5.0..v5.19 | wc -l`). So "kernel 5" and "kernel 6" is a
> > bit too fuzzy to work with.
> 
> 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 on https://snapshot.debian.org/. Please ask if it's
	unclear how to do that.

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

	git rev-list v5.0..v6.0 | wc -l
	311041

to

	$ git rev-list v5.19..v6.0 | wc -l
	16584

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

> > > > In that case the interesting interval is 5.10 .. 6.1. If you could
> > > > pinpoint the oldest kernel image package that shows the symptoms that
> > > > would be great.
> > > I can show only the last official kernels in the correspond Debian
> > > distributive due to their applied in the Live Disks!
> > > 
> > > That is, I have recorded a video when the problem reproduction started, that
> > > is Debian 9 with kernel 4.9.
> > Nobody in the OSS community is interested in 4.9 any more. This kernel
> > version is EOL since January 2023.
> 
> I just say you all history of the problem for detect some relations.
> 
> > 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?
 
> 6.0.0 has this problem like in all 6 kernels.

ok.
 
> > Note that even that might not be enough to spot the problem and you
> > might have to get your hands dirty then and compile development kernels
> > and test them.
> 
> Note, my hands in that "dirty" are 22 years already and I hoped I will not
> get their at least on Linux kernel again — http://oscada.org/wiki/Special:MyLanguage/Sub-projects/Automation_Linux_distributive
> . :)
> 
> And I have resolved the problem for myself by the option "radeon.dpm=0" in
> all my Live Disks. If you want to tell that is my problem, throw it away and
> reject the workaround!:)

There might be a misconception about the roles involved here.

In my eyes the situation is as follows: You have a problem. I (and
possibly others) offer to help. 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.

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.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 5696 bytes --]

Hi, Uwe Kleine-König

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:
>>>>>>>>>> On my hardware that doesn't work and there is no specific.
>>>>>>>>>>
>>>>>>>>>> Now just I set "radeon.dpm=1", I got immediately restart with disabling USB,
>>>>>>>>>> so I have needed to restart for successful download with "radeon.dpm=0".
>>>>>>>>> Can you try a different monitor?
>>>>>>>> I have only one, connected through DVI, and there is no problem on Linux Kernel 5.
>>>>>>> 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)
>>>>>>
>>>>>>>>> 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 on
>>>>>>>>> https://snapshot.debian.org/. Please ask if it's unclear how to do that.
>>>>>>>> I can try all kernels in Debian starting 7 and finishing 13, but I have traced that before and the problem reproduction started from Debian 9, terminated on Debian 11 and renewed on Debian 12.
>>>>> Not sure I follow. Does that mean that Debian 9, Debian 10, Debian 12
>>>>> and Debian 13 show the symptom and Debian 11 doesn't?
>>>> Yes, and in kernels that is 4, 6 show the symptom and 3, 5 don't.
>>> I think this statement isn't helpful unless you're saying that Linux
>>> 5.19 was good and 6.0 was bad. Kernel versions started with 5 between
>>> 2019-03-03 and 2022-07-31, not taking stable releases into account. And
>>> there are 294457 commits in that range
>>> (`git rev-list v5.0..v5.19 | wc -l`). So "kernel 5" and "kernel 6" is a
>>> bit too fuzzy to work with.
>> 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 on https://snapshot.debian.org/. Please ask if it's
> 	unclear how to do that.

I have told that as the kernel in Debian 11.

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

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

>>> Note that even that might not be enough to spot the problem and you
>>> might have to get your hands dirty then and compile development kernels
>>> and test them.
>> Note, my hands in that "dirty" are 22 years already and I hoped I will not
>> get their at least on Linux kernel again — http://oscada.org/wiki/Special:MyLanguage/Sub-projects/Automation_Linux_distributive
>> . :)
>>
>> And I have resolved the problem for myself by the option "radeon.dpm=0" in
>> all my Live Disks. If you want to tell that is my problem, throw it away and
>> reject the workaround!:)
> There might be a misconception about the roles involved here.
>
> In my eyes the situation is as follows: You have a problem.

I have resolved the problem for myself far ago.

> I (and possibly others) offer to help.

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? :)

Regards, Roman

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 5882 bytes --]

Hello Roman,

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 on https://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.

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

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

> > > > Note that even that might not be enough to spot the problem and you
> > > > might have to get your hands dirty then and compile development kernels
> > > > and test them.
> > > Note, my hands in that "dirty" are 22 years already and I hoped I will not
> > > get their at least on Linux kernel again — http://oscada.org/wiki/Special:MyLanguage/Sub-projects/Automation_Linux_distributive
> > > . :)
> > > 
> > > And I have resolved the problem for myself by the option "radeon.dpm=0" in
> > > all my Live Disks. If you want to tell that is my problem, throw it away and
> > > reject the workaround!:)
> > There might be a misconception about the roles involved here.
> > 
> > In my eyes the situation is as follows: You have a problem.
> 
> I have resolved the problem for myself far ago.
> 
> > I (and possibly others) offer to help.
> 
> 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.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Roman Savochenko]

[-- Attachment #1.1: Type: text/plain, Size: 5599 bytes --]

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... :)

[-- Attachment #1.2: Type: text/html, Size: 10207 bytes --]

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Salvatore Bonaccorso]

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

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

[Roman Savochenko]

[-- Attachment #1.1: Type: text/plain, Size: 3791 bytes --]

26.11.25 10:06, Salvatore Bonaccorso:
> 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)
>>
>>>>> 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... :)
> 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.
Are you read the post in the middle or only the end with the trash from Uwe?

Then read the part to which I have nothing to add!!!

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

[-- Attachment #1.2: Type: text/html, Size: 6616 bytes --]

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD

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

[Salvatore Bonaccorso]

Hi Roman,

On Wed, Nov 26, 2025 at 11:15:32AM +0200, Roman Savochenko wrote:
> 26.11.25 10:06, Salvatore Bonaccorso:
> > 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)
> > > 
> > > > > > 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... :)
> > 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.
> Are you read the post in the middle or only the end with the trash from Uwe?
> 
> Then read the part to which I have nothing to add!!!
> 
> > 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)

Yes. And so you have then the last working 5.10.y version and knowing
the next one released in Debian does not work. That means you can
bisect now those two upstream stable series versions to identify which
is the breaking commit with the described procedure to identify the
breaking commit.

Once we have those biection results we might get a better idea with
upstream's help on what do do.

Regards,
Salvatore

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

[Roman Savochenko]

[-- Attachment #1: Type: text/plain, Size: 5549 bytes --]

26.11.25 12:01, Salvatore Bonaccorso:
> On Wed, Nov 26, 2025 at 11:15:32AM +0200, Roman Savochenko wrote:
>> 26.11.25 10:06, Salvatore Bonaccorso:
>>> 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)
>>>>
>>>>>>> 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... :)
>>> 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.
>> Are you read the post in the middle or only the end with the trash from Uwe?
>>
>> Then read the part to which I have nothing to add!!!
>>
>>> 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)
> Yes. And so you have then the last working 5.10.y version and knowing
> the next one released in Debian does not work. That means you can
> bisect now those two upstream stable series versions to identify which
> is the breaking commit with the described procedure to identify the
> breaking commit.

And you? :)

I very well know the bisecting approach, but I have no time, due to I 
have many other unresolved problems to spend this time on them.

> Once we have those biection results we might get a better idea with
> upstream's help on what do do.

Once I fix that, I won't need your participation in whether pushing the 
patch to the upstream or even starting myself builds, especially after 
definition my as a liar by closing the bug with such reasons.

Imagine for your, as an ordinal user will report this bug, when the 
installed system cannot even boot and he beginning Linux from Debian 
9,10,12,13!!! :)

And then imagine, as the ordinal user, who just tried Debian, will go to 
compile many kernels in the bisecting approach for detection the two 
controversy represents in different kernels. :)

And then imaging, as he'll prove the stack of the broken changes in 
mainstream! :)

And I have clashed with that MANY times for not throw myself immediately 
in the mess, when I can just apply the workaround and what I have 
expected from you!

And farewell, since I have no reason of further saying with you after 
the bug closing, since in Debian there "is no problem". :)

[-- Attachment #2: roman.vcf --]
[-- Type: text/vcard, Size: 336 bytes --]

BEGIN:VCARD
VERSION:4.0
EMAIL;PREF=1:roman@oscada.org
FN:Roman Savochenko
ORG:OpenSCADA Team;
TITLE:OpenSCADA author and main developer
N:Savochenko;Roman;;;
ADR:;;;Kamjanske;Sicheslavska;51939;Ukraine
TEL;VALUE=TEXT:+380679859815
URL;TYPE=work;VALUE=URL:http://oscada.org
UID:bc92ca63-75ca-498b-801c-54be2b34328e
END:VCARD