Bug#1118349: dpm broken on Radeon HD 8570D
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
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
Reply to: