[Bug 218305] Ryzen 7 7840HS gets stuck at 544MHz frequency after resuming after unplugging the power cord during sleep

[bugzilla-daemon@kernel.org]

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

--- Comment #68 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> What does EC stand for?

EC is "Embedded Controller".  Here's the ACPI specification for how it is
supposed to be interacted with:

https://uefi.org/specs/ACPI/6.5/12_Embedded_Controller_Interface_Specification.html

It's a black box to anyone but the system manufacturer.

> Might this
> (https://h30434.www3.hp.com/t5/Business-Notebooks/HP-Elitebook-865-G10-w-AMD-Ryzen-9-PRO-7940HS-cannot-sustain/m-p/9061799)
> be related?

> What's weird is that it only happens when I'm using the external monitors
> plugged into the dock, but I don't have any problem if I'm just using the
> dock's ethernet adapter or USB hub.

Yes, it "could" be related. This is getting OT, but if you have enough ports on
your laptop without a dock you could try to plug dongle(s) for monitor(s) and a
regular power adapter and see if you can reproduce the same behavior.

> Easier said that done: they don't care about Linux via the official support
> channels.

:/

> But why does it affect only Linux?

As it pertains to how the sleep wake up works, Linux and Windows work slightly
differently.  Windows has a concept of "dark screen wakeup" after any wakeup
event and will move in and out of hardware sleep while in this state.  Linux
once you get a wakeup event if it's not enough to wake the system (such as the
ACPI SCI but no other interrupt) then it goes back to sleep immediately.

This difference of behavior has uncovered bugs where the X86 cores race for
some of the same resources with the power management firmware on earlier
hardware.

So my working theory has been some timing margins for throttling are not being
met when suspend/resume has occurred under Linux.  That's why I was suggesting
patches to try to keep the kernel alive longer when a power adapter event wakes
the APU.  But the behavior and timing of when to throttle are totally
controlled by the EC.  So if there is a timing problem and forcing the X86
cores to be awake longer doesn't help I'm not sure what else we can do without
HP coming to the table to debug from their EC perspective.

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

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