[Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)

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

 



https://bugzilla.kernel.org/show_bug.cgi?id=216516

--- Comment #14 from Mario Limonciello (AMD) (mario.limonciello@xxxxxxx) ---
> Here's the requested log.

OK let me pull out a few pieces and explain what they mean.

> 2022-09-26T19:01:47.104247+02:00 myhost kernel: [ 2218.148069][    T0]
> Timekeeping suspended for 341.998 seconds
> 2022-09-26T19:01:47.104247+02:00 myhost kernel: [ 2218.148164][ T5798] ACPI:
> EC: ACPI EC GPE status set
> 2022-09-26T19:01:47.104247+02:00 myhost kernel: [ 2218.148190][ T5798] ACPI:
> EC: ACPI EC GPE dispatched
> 2022-09-26T19:01:47.104248+02:00 myhost kernel: [ 2218.148541][ T5798] ACPI:
> EC: ACPI EC work flushed
> 2022-09-26T19:01:47.104248+02:00 myhost kernel: [ 2218.149018][ T5798] ACPI:
> PM: Rearming ACPI SCI for wakeup
> 2022-09-26T19:01:47.104249+02:00 myhost kernel: [ 2568.100347][    T0]
> Timekeeping suspended for 349.998 seconds
> 2022-09-26T19:01:47.104249+02:00 myhost kernel: [ 2568.100442][ T5798] ACPI:
> EC: ACPI EC GPE status set
> 2022-09-26T19:01:47.104250+02:00 myhost kernel: [ 2568.100468][ T5798] ACPI:
> EC: ACPI EC GPE dispatched
> 2022-09-26T19:01:47.104250+02:00 myhost kernel: [ 2568.100817][ T5798] ACPI:
> EC: ACPI EC work flushed
> 2022-09-26T19:01:47.104251+02:00 myhost kernel: [ 2568.101326][ T5798] ACPI:
> PM: Rearming ACPI SCI for wakeup

The SOC was asleep for some number of seconds, and then it got woken up from
the EC GPE.  It may or may not have gone back to the deepest state during each
of these attempts (it's unclear with the way logging works in the kernel).

During the duration of these attempts you can see this happened a LOT of times.

As an educated guess; it might have been that the EC was trying to update new
battery life values or it can be illustrative of another bug.  The easiest way
to determine the cause of these GPEs do the following.

1) Collect the output of 
# grep -v foo /sys/firmware/acpi/interrupts/*
2) Run your suspend
3) Capture again the output of 
# grep -v foo /sys/firmware/acpi/interrupts/*
4) Compare the two to see which incremented

> 2022-09-26T19:01:47.104625+02:00 myhost kernel: [ 4600.944320][ T5798]
> amd_pmc AMDI0005:00: Last suspend in deepest state for 16419799us

This means the SOC was only in the deepest state for a total of 16 seconds of
your last s2idle run.  

> echo disabled > /sys/devices/platform/i8042/serio0/power/wakeup
> echo disabled > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup
> echo XHC1 > /proc/acpi/wakeup

At least for experimentations sake, can you avoid making these changes in your
next attempt?  Would like to confirm they weren't /part/ of this problem.

> Can you tell if the power consumption is completely up to the kernel?

>From the logs you've shared, this is entirely influence by the kernel and
firmware code for your case.  I would not be worried about userspace at all.

If the issue persists even without those wakeup sources then I'll look through
your GPEs.

The next debugging step will be applying the following patches to 6.0-rc:

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=811d59fdf56a17c66742578fe8be8a6a841af448

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=e24faabf5f368c031ad50f0d915a01e1b591f536

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=90bec2855c566b6d07cc3e2bb47befb6266cf1ec

https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/commit/?h=review-hans&id=db55fb8a06f241e168a4f275970f2701d52040c6

Then add this patch:

diff --git a/drivers/platform/x86/amd/pmc.c b/drivers/platform/x86/amd/pmc.c
index e47e54b095af..d3a3e0df6e77 100644
--- a/drivers/platform/x86/amd/pmc.c
+++ b/drivers/platform/x86/amd/pmc.c
@@ -750,6 +750,8 @@ static void amd_pmc_s2idle_check(void)
        struct amd_pmc_dev *pdev = &pmc;
        int rc;

+       usleep_range(10000, 20000);
+
        rc = amd_pmc_write_stb(pdev, AMD_PMC_STB_S2IDLE_CHECK);
        if (rc)
                dev_err(pdev->dev, "error writing to STB: %d\n", rc);

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux