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

[bugzilla-daemon@kernel.org]

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

--- Comment #30 from kolAflash (kolAflash@kolahilft.de) ---
Created attachment 301904
  --> https://bugzilla.kernel.org/attachment.cgi?id=301904&action=edit
kernel log for s2idle with ec_no_wakeup: v6.0-rc7 with bug 216516 comment #25
patches

@Mario
Thanks for answering all my questions!




Here's a new log. ec_no_wakeup=Y and nearly 8 hours of s2idle.
That's 27663 seconds of which 27659 where in the deepest state.

Battery went from 96 % to 80 %. (battery limited to 80 % total power)
That's pretty good compared to without ec_no_wakeup, when the firmware bug
wakes the Linux Kernel. But it's still about 4 times worse than what S3
consumes.

I stumbled upon this commit for the "ThinkPad X1 Carbon 6th" notebook.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8195a655e5ce09550aff81b2573d9b015d520cb9
It's Intel based. But it seems to have a similar problem. So the commit adds a
quirk which sets ec_no_wakeup=true on that notebook.
https://www.thinkwiki.org/wiki/Category:X1_Carbon_(6th_Gen)




(In reply to Mario Limonciello (AMD) from comment #27)
> [...]
> This is a laptop certified with Ubuntu (see
> https://ubuntu.com/certified/202206-30367).  You should contact HP support
> and ask them for a BIOS fix.

(In reply to Mario Limonciello (AMD) from comment #29)
> [...]
> >   SMU Firmware, version 64.61.0
> 
> This is the BIOS component with the bug.  The fix is in 64.66.0.

I also called the HP business support. But they couldn't help me much. They
said "soon" there will be a new BIOS update. But they couldn't tell if it will
contain a new SMU Firmware version.

@Mario
QUESTION:
If there will be a new BIOS version. Should I immediately update? Or should I
keep the current BIOS version for the moment, so we can run a few more tests?
(I'm not sure if a BIOS downgrade would be possible)




> [...]
> (In reply to kolAflash from comment #28)
> > A little more than 1 % of battery was consumed. And I'm wondering if this
> > might contradicts your theory, about the EC trying to notify about a new
> > battery level.
> 
> That amount of time in deep sleep matches how it should be behaving.  If
> that *wasn't* with acpi.ec_no_wakeup=1 then the usleep_range() change is
> helping and I should clean up and send a patch for it too.

ec_no_wakeup was not set when I ran that test. But I think I saw the system
staying in deep sleep before. Even for hours if I didn't opened/closed the lid,
(un)plugged the power, ...
I just feel very uncertain about when this EC GPE background event fires. So
let me run some further checks before committing that usleep_range() patch.




So I see mostly two things remaining now:

1.
Can the power consumption in s2idle be lowered further?
You (Mario) said "For most mobile designs the power consumption is better for
s2idle than S3." So is there something the kernel can do do to bring the power
consumption further down?
S3 is at around 0,5 % battery per hour, because of which I initially tried to
use S3 instead of s2idle. And with ec_no_wakeup=Y I'm getting between 2 % and 3
% battery per hour in s2idle.
(without ec_no_wakeup=Y it was > 10 % per hour if the system left the deepest
state of sleep)

2.
What to do if there's no BIOS update containing the new SMU Firmware?
At least for other Linux users with the EliteBook 845 G8, who don't know
anything about this and don't update their BIOS.
(unfortunately the notebook doesn't support fwupd, so no automatic BIOS updates
when running Linux)
Is ec_no_wakeup=Y the best solution? If yes, maybe add a quirk to the kernel.

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

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