[Bug 221694] [regression v7.0->v7.1] AMD Strix Point (Ryzen AI 9 HX 370) intermittently hangs on resume from s2idle

[bugzilla-daemon@kernel.org]

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

--- Comment #1 from Hongri Cui (hongri.cui@gmail.com) ---
Follow-up on 7.1.1 with amd_pmc.dyndbg=+p enabled.

1) amd_pmc SMU mailbox trace (good cycles) — attached: amd_pmc-dyndbg-7.1.1.txt
A clean suspend/resume shows the PMC<->SMU mailbox completing on every message:
  suspend: AMD_PMC_REGISTER_MESSAGE 7/6/3  -> each AMD_PMC_REGISTER_RESPONSE:1
(OK)
           amd_pmc: SMU idlemask s0i3: 0x7fff1afd
  resume:  AMD_PMC_REGISTER_MESSAGE 3/8    -> each AMD_PMC_REGISTER_RESPONSE:1
(OK)
On every cycle that resumes, all PMC->SMU messages get RESPONSE:1. A wedged
cycle leaves no
trace (journald frozen at suspend entry; box never resumes).

2) amd_pmc unbind test (cf. bug 221664)
  echo AMDI000A:00 > /sys/bus/platform/drivers/amd_pmc/unbind
  # then 30x: rtcwake -m mem -s 30
Result: STILL wedges (cycle 14/30, same silent signature). amd_pmc was
confirmed out of the
path -- zero AMD_PMC_REGISTER_*/SMU traffic after the unbind. So, unlike bug
221664 (where the
same unbind made suspend succeed), this wedge is NOT gated by amd_pmc.
Caveat: with amd_pmc unbound, /sys/power/suspend_stats/last_hw_sleep stopped
updating (stale) --
the platform was no longer entering deep s0i3 (shallow s2idle) -- and it still
wedged. That points
away from the s0i3 firmware handshake and toward the generic suspend/resume
path.

Next: I'll run git bisect v7.0..v7.1 (clean A/B anchors: 7.0.13 is 30/30; 7.1.0
and 7.1.1 both
wedge ~10-40%/cycle). Happy to add no_console_suspend + netconsole to capture
the exact hang point
first if that's more useful. Advice on which welcome.
Attach /var/log/amd_pmc-dyndbg-7.1.1.txt to the comment.

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

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