Public bug reported:
[Impact]
On Dell systems with an AMD APU, plugging in a Thunderbolt dock while the
system is in s2idle wakes it up early. Then the system can't resume. The power
LED blinks an EC power-rail failure code (3 amber, 5 white). The only way out
is a forced power off.
The EC reports SLP_S3#, PLTRST# and RUNPWROK as abnormal. The board-
level cause is SoC leakage on the 0.75V rail. That trips over-voltage
protection (OVP) and the rail powers off.
The amd_pmc driver waits 2.5 seconds before a new HW sleep cycle to
avoid this. The wait is skipped when the dock wakes the system very
briefly.
Failure rate: 100% on affected hardware. Seen on 6.17 OEM kernels. It
does not show up with the amd_pmc driver blacklisted.
[Fix]
The driver used the metrics table (s0i3_last_entry_status) to detect an
intermediate wakeup. The table does not update for every fast wakeup, so the
2.5 second wait was sometimes skipped.
The patch drops the metrics table check. It uses the driver's own
is_first_check_after_suspend state instead.
Upstream commit, in linux-next (not in a released kernel tag yet):
9d45679a02f5e platform/x86/amd: Stop counting intermediate cycles with metrics
table
Fixes: 4dbd11796f3a8 ("platform/x86/amd: pmc: Clear metrics table at
start of cycle"), v6.16.
It needs 037f0b03c663a ("platform/x86/amd/pmc: Don't log during
intermediate wakeups", v7.2), which added is_first_check_after_suspend.
That commit is already in this tree as e1a1c7606406b.
Patch link:
https://patch.msgid.link/[email protected]
[Test Plan]
On a Dell system with an AMD APU and a Thunderbolt dock:
1. Boot to the desktop.
2. Suspend the system:
$ sudo systemctl suspend
3. Plug in the dock while suspended.
4. Unplug the dock, then suspend again.
5. Plug in the dock again.
Without the patch: the system fails to resume and the LED shows 3A5W. A forced
power off is needed.
With the patch: the system wakes up on its own after the dock is plugged in, on
both cycles. No hang, no LED error.
[Where problems could occur]
This could break s2idle suspend and resume on AMD systems that use the amd_pmc
driver.
The wait now depends on is_first_check_after_suspend. If that flag is
wrong, the wait could be skipped and the hang comes back. Or the wait
could run when it isn't needed. Then suspend takes 2.5 seconds longer
after a brief wakeup from USB, Thunderbolt or another device.
The change only removes the metrics table read from the suspend path. It
adds no new hardware calls.
** Affects: hwe-next
Importance: Undecided
Status: New
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Affects: linux (Ubuntu Resolute)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Affects: linux (Ubuntu Stonking)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress
** Tags: dcpl jira-dcpl-39 oem-priority
** Also affects: linux (Ubuntu Resolute)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Stonking)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Resolute)
Status: New => In Progress
** Changed in: linux (Ubuntu Stonking)
Status: New => In Progress
** Changed in: linux (Ubuntu Resolute)
Assignee: (unassigned) => AceLan Kao (acelankao)
** Changed in: linux (Ubuntu Stonking)
Assignee: (unassigned) => AceLan Kao (acelankao)
** Tags added: dcpl jira-dcpl-39 oem-priority
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2168944
Title:
AMD system hangs on resume when a Thunderbolt dock is plugged in
during s2idle
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2168944/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
