LP: #2160183 - 20 second resume is ath12k/MHI waiting out
ATH12K_RESET_TIMEOUT_HZ; fixed in linux-oem-6.17 6.17.0-1030.30, still
open for 7.0
Root Cause Summary
The long resume is entirely ath12k/MHI. Suspend itself is healthy (device
suspend 107 ms, late 2.5 ms, noirq 89 ms, LPS0 entry/exit clean); there is no
ACPI or amdgpu contribution.
Commit 8d5f4da8d70b ("wifi: ath12k: support suspend/resume"), present in 6.17,
suspends the WCN7850 with mhi_power_down_keep_dev()
(ATH12K_MHI_POWER_OFF_KEEP_DEV)
so the MHI child devices survive the cycle, but ath12k_mhi_stop() then still
issues ATH12K_MHI_DEINIT unconditionally. That leaves MHI half torn down: the
BHI image load fails during suspend, POWER_ON returns -ETIMEDOUT, and on resume
ath12k_mhi_start() re-issues INIT which the state machine rejects because
ATH12K_MHI_INIT is still set (mhi state 0x1), so pci_pm_resume_early returns
-22.
The normal resume callback then reaches ath12k_core_resume(), which waits on
ab->restart_completed for ATH12K_RESET_TIMEOUT_HZ (20 * HZ). Nothing ever
completes that restart, so the full 20 seconds is burned. That single device
callback is the entire reported regression: "PM: resume of devices complete
after 20169.451 msecs".
Key Evidence
- PM: suspend entry (s2idle)
- mhi mhi0: MHI did not load image over BHI, ret: -5
- ath12k_pci 0000:01:00.0: failed to set mhi state: POWER_ON(2) / failed to
start mhi: -110
- PM: suspend of devices complete after 107.286 msecs (suspend side is fine)
- ath12k_pci 0000:01:00.0: failed to set mhi state INIT(0) in current mhi state
(0x1)
- ath12k_pci 0000:01:00.0: failed to power up hif during resume: -22
- ath12k_pci 0000:01:00.0: PM: dpm_run_callback(): pci_pm_resume_early returns
-22
- ath12k_pci 0000:01:00.0: timeout while waiting for restart complete / failed
to resume core: -110
- PM: resume of devices complete after 20169.451 msecs (equals
ATH12K_RESET_TIMEOUT_HZ = 20 * HZ)
- fwts: cycle 1 resume 1.259 s (clean), cycles 2-4 resume 20.873 / 20.973 /
20.726 / 20.888 s. The first cycle passing is consistent with the bad MHI
state needing a prior stop to be established. The S2idleNotDeepest (26.86%)
and LongSuspend results are knock-on effects of the stretched wall clock, not
separate defects.
Fix Status
Fixed in OEM 6.17 by "UBUNTU: SAUCE: wifi: ath12k: avoid MHI deinit during
suspend" (skip DEINIT when is_suspend, and skip INIT when ATH12K_MHI_INIT is
already set), released in linux-oem-6.17 6.17.0-1030.30 and verified on this
bug.
Still affected, same kernel version 7.0.14, both carrying 8d5f4da8d70b and
neither carrying the fix:
- OEM 7.0 (oem-7.0-next)
- Generic 7.0 / resolute master-next
Not affected: generic 6.8 (noble master-next) has no ath12k suspend/resume
support at all.
Upstream status: the patch is not merged. It originates from
https://lore.kernel.org/all/[email protected]/
("wifi: ath12k: fix CMA error and MHI state mismatch during resume"). Both
mainline and linux-next still have the unconditional DEINIT. On the ath12k list
Baochen Qiang (Qualcomm) objected that the submitter's underlying "BUG: Bad page
state" in mhi_free_bhie_table() <- mhi_unprepare_after_power_down() is an MHI
stack or DMA/MM lifetime bug rather than an ath12k bug. So this is carried as
SAUCE and needs re-application on every respin until upstream settles.
Secondary Issue - WiFi is not functional on this unit, independent of
the timing fix
This is not addressed by the above patch and probably deserves its own
bug:
- Before suspend (01:50:05) the device was already in a firmware recovery loop:
"failed to send WMI_11D_SCAN_STOP_CMDID: -108", "failed to delete WMI vdev 0:
-108",
then ten "ath12k_pci 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x000f address=0xffd80xxx flags=0x0020]" and "AMD-Vi: IOMMU Event log
restarting", followed by "mhi mhi0: Requested to power ON".
- Every WMI operation fails with -108 from that point onward (54 occurrences),
continuing past resume to 01:53:19: "failed to enable PMF QOS: -108",
"fail to start mac operations in pdev idx 0 ret -108".
- IwConfig shows "wlp1s0 no wireless extensions", i.e. no working wiphy.
- Checkbox therefore skipped suspend/network_before_suspend and "Verify the
network functionality after system resume".
- IO_PAGE_FAULT from the WiFi device on an AMD IOMMU platform during firmware
recovery is a DMA-after-teardown signature, plausibly the same class of MHI
buffer lifetime problem raised upstream.
- The unit ran firmware WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
with linux-firmware 20240318.git3b128b60-0ubuntu2.27. linux-firmware upstream
has since moved WCN7850 hw2.0 to WLAN.HMT.1.1.c7-00108.
A passing fwts s3 on 6.17.0-1030.30 therefore does not by itself prove WiFi
survives suspend/resume on this machine.
Recommended Actions
1. OEM 6.17: nothing further, fix shipped in 6.17.0-1030.30 and verified.
2. Port the fix to OEM 7.0 (oem-7.0-next) and generic 7.0 (resolute
master-next). Both are 7.0.14, both have 8d5f4da8d70b, neither has the fix,
so the same 20 second regression is live there. This covers the open
linux (Ubuntu Resolute) task.
3. Keep the upstream discussion moving, otherwise the SAUCE becomes permanent
carry. The durable fix most likely belongs in drivers/bus/mhi (BHIE table
lifetime) rather than in ath12k.
4. Re-test actual WiFi association and traffic across suspend/resume on
6.17.0-1030.30 or later with linux-firmware bumped to WCN7850 c7-00108, and
file the -108 / AMD-Vi IO_PAGE_FAULT recovery loop as a separate bug if it
persists.
5. Generic 6.8 needs no action.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160183
Title:
Suspend resume time is too long on EliteBook 8 G1a 13
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2160183/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
