glymur: hard reset on the first system-domain idle entry (SS3, 0x0200c354) after a heavy load - Lenovo Yoga Slim 7x Gen 11

glymur: hard reset on the first system-domain idle entry (SS3, 0x0200c354) after a heavy load - Lenovo Yoga Slim 7x Gen 11

[Oleg Keri]

Hi,

Lenovo Yoga Slim 7x Gen 11 (Glymur / Snapdragon X2 Elite), linux-next
next-20260908 with Konrad's board DTS (now in next) [1], OSI mode ("Initialized CPU
PM domain topology using OSI mode"), Ulf's "pmdomain/cpuidle-psci: Fix
behaviours for CPU PM domains" v3 applied.

Symptom: after any full-speed all-core load - a kernel build (~85 s
here), `stress --cpu 18 --timeout 90`, rust-analyzer indexing - the
machine hard-resets once it goes idle: about one second of freeze, then
the firmware splash.  Nothing is logged, the APSS watchdog's bootstatus
reads 0 afterwards, no pstore.  5 out of 5 attempts, 15 s to 3 min after
the load ends.  Steady idle without a preceding load never resets, for
hours.

What isolates it to SS3:

- Deleting domain-idle-states from power-domain-system in the board DTS
  (so 0x0200c354 is never requested; CL5 untouched) survives the same
  trigger 3 out of 3, through tens of thousands of cluster collapses.
- On a quiet machine SS3 is entered hundreds of times right after boot
  and survives every time.  Only the first SS3 entry after a load kills.
  psci_domain_idle_enter filtered on state==0x200c354 shows no earlier
  request in the post-load window; the fatal one is the first.
- The state's latencies are not the variable: it resets with
  glymur.dtsi's entry 2800 / exit 4400 / residency 10150, with the vendor
  DSDT _LPI figures (entry 0 / exit 5000 / residency 9000, a local
  change I carry), and with entry 5000 / exit 5000 / residency 9000.

Ruled out by direct test, each with the same trigger:

- NoC QoS programming (reg removed from all 19 interconnect providers so
  icc-rpmh skips it): still resets.
- cpufreq transitions (all policies pinned with the performance
  governor): still resets.
- NVMe/PCIe I/O: `stress --cpu 18` with no I/O resets too.
- PDC secondary mode: the PDC config register named in the vendor DSDT
  (\_SB_.GIO0.PDCC = 0x0b220110, mask PDCM = 0x35430) reads 0x4, i.e. 0
  under the mask.

So the question: is SS3/CxPC expected to be usable as a runtime idle
state on Glymur?  x1e80100 only got domain_ss3 in DT once the PDC
pass-through configuration landed (95f827ceb21e), while glymur.dtsi has
carried it since the base dtsi.  Is there a firmware or PDC prerequisite
this board does not meet, or should glymur drop domain_ss3 from
power-domain-system the way x1e did until then?

What I run meanwhile: min-residency-us = <4000000000> on domain_ss3.
cpu_power_down_ok() then never admits SS3 at runtime, while the s2idle
path (cpu_system_power_down_ok() checks latency only) still takes it.
Three hours, a rebuild, three suspends and a stress cycle: zero runtime SS3
entries, s2idle entered SS3 every time, no reset, and s2idle draw is
unchanged at ~300 mW.  I am not proposing
that as a patch - a residency value is a hint, not a switch - but it
does say SS3 is fine as a suspend state here and only fatal at runtime.

Happy to test patches or collect anything else; the reproducer takes
three minutes.

Thanks,
Oleg

[1] https://lore.kernel.org/all/20260731-topic-yoga_submission-v2-0-f1887031da4f@oss.qualcomm.com/