[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 #28 from kolAflash (kolAflash@xxxxxxxxxxxx) ---
Created attachment 301897
  --> https://bugzilla.kernel.org/attachment.cgi?id=301897&action=edit
kernel log for s2idle: v6.0-rc7 with bug 216516 comment #25 patches - 30
minutes of s2idle

(In reply to Mario Limonciello (AMD) from comment #27)
> [...]
> I don't have any evidence that the usleep_range() change helped in any way,
> so I won't send that for now.
> 
> If you discover that is required for good battery life on your side let me
> know and I'll cleanup a more proper variation of it to send out.

I'll try to run some tests.
Just to get this right:
Is the usleep_range() patch about helping with the buggy interrupts?

Or is is about further lowering the power consumption below 2 % per hour?
(2 % per hour is the best I got until now, when the deepest state was active
all the time)




> > Here are the first results.
> 
> OK so the idle mask doesn't "change" from one time to another in any
> unexpected ways to me.
> 
> > [   90.048438] PM: Triggering wakeup from IRQ 9
> > [   90.048801] PM: Triggering wakeup from IRQ 1
> 
> When you see two IRQs like this; it's a firmware bug as described in the
> other report I mentioned above.  HP will need to issue a new BIOS to fix
> this.

All tests where made with BIOS version 01.10.00 Rev.A (released 2022-08-09 /
build 2022-07-13)
This is the most recent BIOS version available.
https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-elitebook-845-g8-notebook-pc/38492638/model/2100000127/swItemId/ob-294554-1?sku=5Z621EA
See "Revision history":
  Embedded Controller (EC), version 43.2D.00
  PSP Firmware, version 0.11.0.79
  SMU Firmware, version 64.61.0
  AMD GOP EFI Driver AMD GOP X64 Release Driver, version 2.16.0.17.10
  Cypress Power Delivery (PD) Firmware, version 0.7.0

I got no Windows installed. But I'm wondering how Windows is handling this
firmware bug?




> 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.

Does "certified with Ubuntu" mean HP is officially supporting it?
Or does this mean, that just Ubuntu says it's working?

I can try posting the HP support for HP support forum or calling the HP
business support hotline. But most of the it's quite hard to get real help from
them.
https://h30434.www3.hp.com/t5/Business-Notebooks/bd-p/General
Wouldn't it be better, if you - as official AMD employee - report this to HP!?




> > [  332.466583] PM: Triggering wakeup from IRQ 9
> 
> When you're seeing these alone in the middle of the sleep it's because of
> the EC GPE firing to do $something.  In this case I believe it's the EC
> trying to notify a new battery level.  Due to the above bug I mentioned I
> think these together will "prevent" it from going back to the deepest state.

EC means "Embedded Controller"?
GPE means "General Purpose Event"?

Maybe I can more explicitly test if it's the battery level.
Removing the battery is possible. It's just a little more effort.
But instead I could fully charge the battery and put the notebook into s2idle
with AC power connected. In that case the battery level shouldn't change. So no
event should happen, if I DON'T I press the keyboard, (un)plug the ac power or
open/close the lid.


I attached another log:

System was in s2idle for 30 minutes without interruption (deepest state the
whole time). System was on battery power (no ac power connected). And comment
#25 (including comment #14) patches where applied. I just opened and closed the
lid 30 seconds before waking the system using the power button. So the system
wasn't in deepest state of sleep.

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 workaround works very well! Thanks :-)
> 
> Sure.  This is going to limit you quite a bit in terms of wakeup sources,
> but IMO I think it's a worthwhile trade off for this problem.  You should
> hopefully be getting much better power consumption now over s2idle.

I'm a late riser person. And I also like my notebook to stay asleep, unless I
press the power button ;-)

So I'll go to bed now. And I'll also put the notebook on battery (no ac power
connected) and into s2idle with the ec_no_wakeup workaround enabled. So
tomorrow morning I'll see how much power it has consumed using the ec_no_wakeup
workaround :-)

-- 
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 Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux