[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1118349: dpm broken on Radeon HD 8570D



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