Package: src:linuxnow. Note that I didn't upgrade or install any other packages in between, only using a different Linux kernel from Debian, and now the situation doesn't occur anymore.
Version: 6.1.140-1
Severity: serious
Justification: Policy 11.8.1
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Resume from suspend-to-disk keeps screen dark. The system is running, and is accessable via network, but no X11.
* What exactly did you do (or not do) that was effective (or
ineffective)?
acpitool -S; reboot, input of disk encryption password
* What was the outcome of this action?
Two dark monitors, which report no HDMI and (the other) no DisplayPort signal
* What outcome did you expect instead?
My window system was expected, with a X11 windows and mouse.
* Additional, maybe helpful information:
I've a AMD Ryzen 7 5700G system, where the on-chip GPU is used as the only graphic card, and where no additional graphic card is installed.
I saw this in 3 of 3 times, after upgrading to linux-image-6.1.0-37-amd64 kernel. Running the old, saved linux-image-6.1.0-34-amd64 kernel package (kernel 6.1.135-1) - selection via grub - , the situation doesn't occur and the resumes are solid
Control: tags -1 + moreinfo
Hi,
On Sun, Jun 08, 2025 at 01:55:23PM +0200, Klaus Singvogel wrote:
Thanks for your report.
Can you please report here a full boot long once triggering the issue
with the 6.1.140-1 please from boot, to suspend and then resume.
Your system appears to be tainted furthermore with
TAINT_PROPRIETARY_MODULE and out of tree modules, so we need to se as
well what those are.
Hi,solid now. Note that I didn't upgrade or install any other packages in between, only using a different Linux kernel from Debian, and now the situation doesn't occur anymore.
Salvatore Bonaccorso wrote:
Control: tags -1 + moreinfo
Hi,
On Sun, Jun 08, 2025 at 01:55:23PM +0200, Klaus Singvogel wrote:
Package: src:linux
Version: 6.1.140-1
Severity: serious
Justification: Policy 11.8.1
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Resume from suspend-to-disk keeps screen dark. The system is running, and is accessable via network, but no X11.
* What exactly did you do (or not do) that was effective (or
ineffective)?
acpitool -S; reboot, input of disk encryption password
* What was the outcome of this action?
Two dark monitors, which report no HDMI and (the other) no DisplayPort signal
* What outcome did you expect instead?
My window system was expected, with a X11 windows and mouse.
* Additional, maybe helpful information:
I've a AMD Ryzen 7 5700G system, where the on-chip GPU is used as the only graphic card, and where no additional graphic card is installed.
I saw this in 3 of 3 times, after upgrading to linux-image-6.1.0-37-amd64 kernel. Running the old, saved linux-image-6.1.0-34-amd64 kernel package (kernel 6.1.135-1) - selection via grub - , the situation doesn't occur and the resumes are
Thanks for your report.
Can you please report here a full boot long once triggering the issue
with the 6.1.140-1 please from boot, to suspend and then resume.
Find it attached.
While the OOT is not directly related, can you confirm that you get
the same problem if you do not load the OOT wl module?
If yes, the next step would be to report it upstream at https://gitlab.freedesktop.org/drm/amd with the full boot log attached
ot the report there (there are similar, but not identical reports
filled there, but closed).
Hi Salvatore,
Salvatore Bonaccorso wrote:
While the OOT is not directly related, can you confirm that you get
the same problem if you do not load the OOT wl module?
I blacklisted the wl module, and the kernel no longer reports, that it's tained, but the issue persists.
If yes, the next step would be to report it upstream at https://gitlab.freedesktop.org/drm/amd with the full boot log attached
ot the report there (there are similar, but not identical reports
filled there, but closed).
I filed this report: https://gitlab.freedesktop.org/drm/amd/-/issues/4330
Hello Klaus,
http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.15-amd64_6.15.2-1%7eexp1_amd64.deb
and then install it using
dpkg -i linux-image-6.15-amd64_6.15.2-1~exp1_amd64.deb
dpkg -i linux-image-6.15-amd64_6.15.2-1~exp1_amd64.deb
Thanks.
The first installation was aborted, due to the wrong version of linux-base (>= 4.12 was required, but 4.9 was installed).
But after installing linux-base_4.12~bpo12+1_all.deb, the linux kernel 6.15.2 was successfully installed. Yippie.
The issue doesn't occur in kernel 6.15.2.
Hello Salvatore,
Klaus Singvogel wrote:
dpkg -i linux-image-6.15-amd64_6.15.2-1~exp1_amd64.deb
Thanks.
The first installation was aborted, due to the wrong version of linux-base (>= 4.12 was required, but 4.9 was installed).
But after installing linux-base_4.12~bpo12+1_all.deb, the linux kernel 6.15.2 was successfully installed. Yippie.
The issue doesn't occur in kernel 6.15.2.
Upstream suggests testing kernel version 6.1.141.
https://gitlab.freedesktop.org/drm/amd/-/issues/4330
Mario thinks that this missing patch might be the cause of the issue:
https://git.kernel.org/torvalds/c/7e7cb7a13c81
Is the 6.1.141 kernel available as a Debian package anywhere, like
the 6.15.2 experimental version?
Hi Klaus,
On Wed, Jun 18, 2025 at 07:54:55PM +0200, Klaus Singvogel wrote:
Hello Salvatore,
Klaus Singvogel wrote:
dpkg -i linux-image-6.15-amd64_6.15.2-1~exp1_amd64.deb
Thanks.
The first installation was aborted, due to the wrong version of linux-base (>= 4.12 was required, but 4.9 was installed).
But after installing linux-base_4.12~bpo12+1_all.deb, the linux kernel 6.15.2 was successfully installed. Yippie.
The issue doesn't occur in kernel 6.15.2.
Upstream suggests testing kernel version 6.1.141.
https://gitlab.freedesktop.org/drm/amd/-/issues/4330
Mario thinks that this missing patch might be the cause of the issue:
https://git.kernel.org/torvalds/c/7e7cb7a13c81
Is the 6.1.141 kernel available as a Debian package anywhere, like
the 6.15.2 experimental version?
No not yet, as it is yet in preparation.
I can do two things for you, 1. provide the 6.1.141 based test package version and both a test version with only 7e7cb7a13c81073d38a10fa7b450d23712281ec4 applied to confirm that is
the isolated fix.
will come back to you when it's ready to test. Alterantively you can
do the following, with the attached patch (which is the mentioned
commit, follow https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
which uses a helper script to make test packages using single patches
on top quite handy/easy.
I have built 6.1.140-1 with the single patch on top in https://people.debian.org/~carnil/tmp/linux/1107511/
Along I generated a sha256 sum file for the files and signed it with
the gpg for me in the Debian keyring, as we cannot provide signed
packages.
With the disclaimer that they are test-packages, it would be great if
you can test this.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (2 / 14) |
Uptime: | 149:58:23 |
Calls: | 10,383 |
Files: | 14,054 |
Messages: | 6,417,784 |