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.
