5.11 frozen screen after suspend - renoir

changed the description

Did it work fine on 5.10? Your problem seems to be related to issue #1230 (closed).

The suspend works fine as far as I can tell. Swaylock enables as expected and the light on the side begins to pulse. It works fine on 5.10 - I've reverted for now and it resumes from suspend without issue.

Same issue on 4700U.

I have enabled S3 support via patched ACPI tables. It seems like a regression in 5.11, as resuming from suspension works as expected on 5.10.

Yeah, this is also how I've enabled S3 support. I also tried rebuilding the patched ACPI tables in 5.11, but it didn't make any difference.

The Fence fallback timer expired on ring sdma0 error message I have reported before on the same GPU by #1381

It happens about 1 out of 4 boots. I am wondering if it could be related to the BIOS setting Decode above 4G.

To find a pattern (besides the same GPU), is this setting enabled in your BIOS?

The configuration options in the BIOS on the 14are05 are pretty limited. I don't see anything about Decode above 4G in there. The iGPU config options are entirely limited to being able to increase the amount of VRAM allocated.

The laptop I use is a Xiaomi RedmiBook 16, which also has a very limited BIOS. There are no options whatsoever related to GPU (or any other hardware for that matter), just basic options such as secure boot and the boot order.

I use S3 suspension with patched ACPI tables on Redmibook 14 ii (AMD Ryzen 4500U) and have this issue as well. It used to work on 5.10.

Same issue on Lenovo IdeaPad 5 14ARE05, AMD Ryzen 7 4700U with Radeon Graphics Linux fedora 5.11.0-156.fc34.x86_64

I don't know how to switch to 5.10 on Fedora 34. Could this be fixed in 5.11.x ?

I'm currently bisecting the kernel to see which commit introduced this issue. Needs some time.

Might be related: http://lkml.iu.edu/hypermail/linux/kernel/2012.2/04791.html

Hi there, I ran into the same issue as @alexmaras

Following the link posted by @marius.andreiana , i tried to restore the "default" s2idle suspend state (the one that gave me the same issue as above), reverting the DSDT patch that gave me the S3 suspend state. Well, resume from suspend now works as expected, though i got some errors in dmesg.

Hardware description:

CPU: AMD Ryzen 7 4700U
GPU: Radeon RENOIR
System Memory: 16GB DDR4 SODIMM
Display(s): Builtin Laptop Display
Type of Diplay Connection: eDP

System infomration:

Distro name and Version: Arch Linux
Kernel version: 5.11.1-zen1-1-zen
Custom kernel: N/A
AMD package version: 19.1.0-2

dmesg.txt

Ciao Roberto, what exactly did you do to get it working? Did you modify the 5.11 kernel to remove the patch at http://lkml.iu.edu/hypermail/linux/kernel/2012.2/04791.html ? Then did you also apply this change? https://nns.ee/blog/2020/10/18/acpi-patching.html

Ciao @marius.andreiana, I removed the patched DSDT so i lost the S3 suspend option but I regained a functioning s2idle option.

BTW I spoke too soon, after a couple of suspend/resume cycles (in s2idle mode), the old bug is back.

I'll be wait for a fix. :)

I have bisected the issue to the commit 628c36d7b238e2d72158e8aba229ec79c69c157e:

commit 628c36d7b238e2d72158e8aba229ec79c69c157e
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Wed Sep 9 14:40:24 2020 +0800

    drm/amdgpu: update amdgpu device suspend/resume sequence for s0i3 support

    - Need skip the RLC/CP/GFX disable for let GFXOFF enter during suspend period.
    - For s0i3 suspend only need suspend DCE and each IP interrupt.
    - Before VBIOS POSTed check and atom HW INT need set the GPU power status change
      to D0 in the resume period, otherwise the HW will be mess up and see the SDMA hang.
    - Need handle the GPU reset path during amdgpu device suspend.

    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Acked-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

In particular, checks have been added in various places for amdgpu_acpi_is_s0ix_supported(), which succeeds on hardware with this issue. However, what hasn't been taken into account is that just because this check succeeds doesn't mean the system is entering S0 - in our case, the system is entering S3 instead.

agd5f/linux@b092b196 should maybe fix this issue, but I need a few minutes to test this. (edit 2: it does not)

I will update the article at https://nns.ee/blog/2020/10/18/acpi-patching.html to include a notice about this issue until this is fixed in a kernel release. (edit: notice added)

Thanks so much, Rasmus!

until this is fixed in a kernel release

Is there a new issue we should file for this? How will the proper maintainer find out?

With agd5f/linux@b092b196, an additional patch is needed to make resuming from S3 suspension work properly:

drm/amdgpu: fix failure to resume from S3 suspension

If a system supports s0i3 sleep state but enters s3, amdgpu fails to
resume from sleep properly. Add an additional check and un-gate as
necessary.

Fixes: 628c36d7b238e2 ("drm/amdgpu: update amdgpu device suspend/resume sequence for s0i3 support")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1503
Signed-off-by: Rasmus Moorats <xx@nns.ee>


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6447cd6ca5a8..c3f2eb520ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2678,7 +2678,7 @@ static int amdgpu_device_ip_suspend_phase1(struct amdgpu_device *adev)
 {
        int i, r;

-       if (adev->in_poweroff_reboot_com ||
+       if (adev->in_poweroff_reboot_com || adev->in_suspend ||
            !amdgpu_acpi_is_s0ix_supported(adev) || amdgpu_in_reset(adev)) {
                amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
                amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
@@ -3742,7 +3742,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool fbcon)

        amdgpu_fence_driver_suspend(adev);

-       if (adev->in_poweroff_reboot_com ||
+       if (adev->in_poweroff_reboot_com || adev->in_suspend ||
            !amdgpu_acpi_is_s0ix_supported(adev) || amdgpu_in_reset(adev))
                r = amdgpu_device_ip_suspend_phase2(adev);
        else
--
2.30.1

I do not know what the implications of this patch are besides fixing S3. I'm unfortunately not familiar with amdgpu that much.

EDIT: Fairly certain the second adev->in_suspend check is useless as it will always succeed (it is set to true in the same function). I need someone with experience with amdgpu to write a proper patch :) This is just a quick fix.

That will break S0ix. Do you have the AMD PMC (CONFIG_AMD_PMC) driver loaded on your system? Does this patch help?

0001-drm-amdgpu-Only-check-for-S0ix-if-AMD_PMC-is-configu.patch

$ zcat /proc/config.gz | grep AMD_PMC
CONFIG_AMD_PMC=m

$ lsmod | grep pmc
amd_pmc                20480  0

The patch seems to work - resuming from S3 suspension works as expected. Tested against mainline commit 2c87f7a3.

resuming from S3 suspension works as expected

Are the steps at https://nns.ee/blog/2020/10/18/acpi-patching.html still required with this patch? I have only S0:

#  cat /sys/power/mem_sleep
[s2idle]

# uname -a
Linux fedora 5.11.0-156.fc34.x86_64

# lsmod|grep pmc
amd_pmc                20480  0

Not sure what you mean, I still use deep suspension into S3 (with patched ACPI tables, as in the article) because s2idle keeps the machine too awake and drains the battery.

I just tested s2idle - I removed the patched ACPI tables and let the system default on s2idle, and the system (or amdgpu) no longer resumes from suspend. Using the patched ACPI tables and deep suspension is the only method for working suspension, which doesn't seem right.

mentioned in commit agd5f/linux@b092b196

I removed the patched ACPI tables and let the system default on s2idle, and the system (or amdgpu) no longer resumes from suspend.

That's what I get too (kernel 5.11, no patches)

So there are still 2 bugs:

s2idle doesn't resume from suspend
S3 doesn't work by default, needs patched ACPI tables

The following branch should have everything you need for S0ix (modern standby) on AMD renoir platforms (barring any additional OEM specific requirements we haven't found yet): https://gitlab.freedesktop.org/agd5f/linux/-/commits/s0ix Please make sure you enable CONFIG_AMD_PMC in your config otherwise, you won't have the ACPI power management platform driver for AMD platforms.

If you don't want to use this branch, you will need at least the following patches:

With this branch:

CONFIG_AMD_PMC=m:

S3 suspension works as intended with patched ACPI tables. No issues with entering or resuming from suspension.
s2idle fans stop spinning, graphics goes dark and backlight is turned off, but the power led stays on. Cannot get system to resume from this state.

CONFIG_AMD_PMC=y:

Cannot enter S3 sleep with patched ACPI tables. Power LED stays on when entering suspension, which is abnormal for S3 (at least for me). Visually the same as s2idle above. Cannot get the system to resume.
s2idle - same as above.
Overall, suspension does not work at all.

I can't apply half these patches to 5.12 which is frustrating since I don't wanna go back in kernels if I don't have to, I just want to test if this works. @agd5f do you by chance have patches for 5.12?

See #1230 (closed) for the latest.

@agd5f and anyone else that might be reading. I just tested this on may 10th 2021.

I applied the 6 patches (dated 4/12/2021) found here

I applied them to a 5.11.0 vanilla kernel, a 5.12, and also 5.13RC1.

all 3 suspend completely fine on a 14ARE05 (ideapad 5 with a 4500U)

The catch is I had to remove the ACPI dsdt fix that was suggested in a million other sources. Once I add that back in, it all fails again. and to test whether I was entering actual s3, I saw blinking lights, and over the course of 8 hours I lost less than 2% battery power.

I also tried 5.11, 5.12, 5.13RC1 vanilla with and without the ACPI fix to see what combination would work. All of them failed to suspend.

Again let me reiterate: 6 patches applied to your kernel, no acpi fix at all WILL suspend s3. Fantastic work Alex!

https://gitlab.freedesktop.org/agd5f/linux/-/commits/s0ix-8

I Know this is also mentioned elsewhere on this thread but I tried to give as much information as possible.

@agd5f have you submitted a PR or bug report to kernel.org team?

We are working to get all of the changes upstream. The GPU driver changes are uptream. The other ones are slowly making their way in.

added Renoir label

Another mention of patched ACPI working prior to 5.11.7 with some details #1230 (comment 847230)

1st failure to resume from suspend (after ~8 successful resumes) with

fedora-5.11-s0ix-6 
Revert "platform/x86: force LPS0 functions for AMD"
Revert "platform/x86: Add missing LPS0 functions for AMD"

Pressed power button, fan started briefly, led turned from sleep to on, then nothing. Keyboard caps lock didn't turn on light. Don't have another box to ssh from.

Except this, battery consumption over another night was 4%. No quirks.

journalctl.txt

Can't see errors:

ar 19 23:42:45 fedora systemd[1]: Reached target Sleep.
Mar 19 23:42:45 fedora systemd[1]: Starting Suspend...
Mar 19 23:42:45 fedora systemd-sleep[73018]: Suspending system...
Mar 19 23:42:45 fedora kernel: PM: suspend entry (s2idle)
-- Boot e6d856cbbfe44fe69684c3d37d2db5e3 --
Mar 20 08:05:56 fedora kernel: Linux version 5.11.7-200.s0ix06revert1.fc34.x86_64 (marius@fedora) (gcc (GCC) 11.0.0 20210210 (Red Hat 11.0.0-0), GNU ld version 2.35.1-38.fc34) #1 SMP Thu Mar 18 09:52:40 EET 2021

Update with Linux 5.12. Similar result - a completely blank, unresponsive display. Changing TTY lets me do things, but nothing in that display recovers.

I can confirm the issue since upgrade Ubuntu 20.10 (kernel 5.8) to Ubuntu 21.04 (kernel 5.11). I use a patch for advertising of support for S3 that worked for me with kernel 5.8.

With kernel 5.11 when I sleep my laptop (close lid) and then open lid, screen remains black. As a workaround I switched to kernel 5.10.35 (ubuntu-mainline-kernel.sh allows installation of any kernel into Ubuntu).

My laptop is Yoga Slim 7 14ARE05 with Ryzen 47000U

just a reminder to save time...

5.11 frozen screen after suspend - renoir

Brief summary of the problem:

Hardware description:

System infomration:

How to reproduce the issue:

Attached files:

Designs

Child items ...

Activity

Hardware description:

System infomration:

Admin message

Admin message

5.11 frozen screen after suspend - renoir

Brief summary of the problem:

Hardware description:

System infomration:

How to reproduce the issue:

Attached files:

Activity

Hardware description:

System infomration: