From: bugzilla-daemon@kernel.org
To: platform-driver-x86@vger.kernel.org
Subject: [Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU)
Date: Wed, 28 Sep 2022 23:45:57 +0000 [thread overview]
Message-ID: <bug-216516-215701-e1JEBVuhaq@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-216516-215701@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=216516
--- Comment #24 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301894
--> https://bugzilla.kernel.org/attachment.cgi?id=301894&action=edit
kernel log for s2idle: v6.0-rc7 with bug 216516 comment #14 patches - 23
minutes of s2idle
@Mario
Yes, it's definitely an intermingled mess...
If you have an idea how I can help to untangle this, please give me detailed
instructions which tests I should run.
If you think this will help, we can have a (video) call about this. Just send
me an email with date + time. (I live in UTC+2)
Just tell me which (video) call tool you like to use. I'm open for pretty much
everything (Jitsi-Meet, Skype, Mumble, XMPP, Matrix, ...)
Something about the sysfs and procfs settings I'm doing:
This is needed to disable wakeup from USB events in S3 suspend.
echo XHC1 > /proc/acpi/wakeup
Actually I wouldn't need to set this for s2idle.
In future I'll leave this out for s2idle tests.
This is needed to prevent the system from waking on keyboard events and on
closing the lid.
echo disabled > /sys/devices/platform/i8042/serio0/power/wakeup
And additionally this is needed to prevent the system from waking on opening
the lid.
echo disabled > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/power/wakeup
(both, i8042 and LNXSYBUS:00/PNP0C0D:00, must be disabled to prevent wake on
opening the lid)
Additionally, if i8042 and LNXSYBUS:00/PNP0C0D:00 are not disabled, the system
tends to wake after some minutes from s2idle. Maybe something between 10 or 60
minutes.
I haven't figured out yet if this is related to just one or both settings.
So beside the lid open/close, keyboard and AC power events, there must be
something else interrupting the suspend. Something which is totally without
user interaction, because these wakes also appear if I leave the lid open and
don't touch the notebook at all.
I rebooted the system and then put it into s2idle for a little more than 23
minutes (1400 seconds).
See these lines:
Thu Sep 29 00:09:19 CEST 2022
Thu Sep 29 00:33:12 CEST 2022
Everything, including all sysfs setting I made, is documented in the log.
And I didn't closed the lid this time. I didn't even touched the notebook
during that 23 minutes.
These lines suggest, that the system didn't stay in "deepest state" of sleep
the whole time.
[ 92.340524] PM: suspend-to-idle
[ 92.340549] ACPI: EC: ACPI EC GPE status set
[ 92.340562] ACPI: PM: Rearming ACPI SCI for wakeup
[ 92.364660] Timekeeping suspended for 759.694 seconds
[ 92.364660] ACPI: EC: ACPI EC GPE status set
[ 92.364680] ACPI: EC: ACPI EC GPE dispatched
[ 92.364987] ACPI: EC: ACPI EC work flushed
[ 92.364987] ACPI: PM: Rearming ACPI SCI for wakeup
[ 92.383963] ACPI: EC: ACPI EC GPE status set
[ 92.383981] ACPI: PM: Rearming ACPI SCI for wakeup
[ 92.408334] Timekeeping suspended for 331.956 seconds
[ 92.408334] ACPI: EC: ACPI EC GPE status set
[ 92.408334] ACPI: EC: ACPI EC GPE dispatched
[ 92.408340] ACPI: EC: ACPI EC work flushed
[ 92.408340] ACPI: PM: Rearming ACPI SCI for wakeup
[ 92.429810] Timekeeping suspended for 328.978 seconds
[ 92.429810] ACPI: EC: ACPI EC GPE status set
[ 92.429810] ACPI: EC: ACPI EC GPE dispatched
[ 92.429815] ACPI: EC: ACPI EC work flushed
[ 92.429815] ACPI: PM: Rearming ACPI SCI for wakeup
[ 92.451340] Timekeeping suspended for 8.978 seconds
[...]
[ 92.451340] amd_pmc AMDI0005:00: Last suspend in deepest state for
758373565us
To it looks pretty much like the deepest sleep was only for the first 758
seconds.
The remaining time of the altogether ~ 1400 seconds the system wasn't in the
deepest state.
I guess that the deepest state has been interrupted by the remnant of what
completely wakes the system if i8042 and LNXSYBUS:00/PNP0C0D:00 are not
disabled (see above).
I set the BIOS to limit the battery to max. 80 %. This usually drastically
increases the overall lifetime of lithium-ion batteries. That's what makes the
difference between energy-full and energy-full-design in the log.
These are the power consumption values:
energy-full-design: 53.0145 Wh
22.2222/(53.0145/100) = 41.9 %
20.8824/(53.0145/100) = 39.4 %
So about 2.5 % of power (1.3398 Wh) was consumed.
If the system was in perfect s2idle, this should have been less than 1% for 23
minutes.
Bug 2.5 % pretty much matches about 700 seconds of "bad" s2idle after the
initial 700 "good" s2idle seconds in deepest state.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2022-09-28 23:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-216516-215701@https.bugzilla.kernel.org/>
2022-09-26 18:49 ` [Bug 216516] s2ram freezes screen (Ryzen-5650U incl. Radeon GPU) bugzilla-daemon
2022-09-27 13:15 ` bugzilla-daemon
2022-09-27 18:00 ` bugzilla-daemon
2022-09-27 18:05 ` bugzilla-daemon
2022-09-27 18:07 ` bugzilla-daemon
2022-09-28 15:55 ` bugzilla-daemon
2022-09-28 16:29 ` bugzilla-daemon
2022-09-28 16:36 ` bugzilla-daemon
2022-09-28 16:57 ` bugzilla-daemon
2022-09-28 17:06 ` bugzilla-daemon
2022-09-28 23:45 ` bugzilla-daemon [this message]
2022-09-29 21:14 ` bugzilla-daemon
2022-09-29 23:29 ` bugzilla-daemon
2022-09-29 23:52 ` bugzilla-daemon
2022-09-30 0:37 ` bugzilla-daemon
2022-09-30 1:01 ` bugzilla-daemon
2022-09-30 10:38 ` bugzilla-daemon
2022-09-30 12:32 ` bugzilla-daemon
2022-09-30 15:50 ` bugzilla-daemon
2022-10-03 17:21 ` bugzilla-daemon
2022-10-12 17:39 ` bugzilla-daemon
2022-10-12 17:53 ` bugzilla-daemon
2022-10-12 18:04 ` bugzilla-daemon
2022-10-13 1:17 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-216516-215701-e1JEBVuhaq@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox