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/

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

[Joonhoe Kim]

Hi,

A data point from Kaanapali (SM8850), which has the same domain states
(cluster 0x01000054, system 0x0200c354): Lenovo Legion Tab Y700 Gen 5,
v7.3-rc4, PSCI OSI mode, with the CPU PM domains split in two cluster
domains (CPU0-5, CPU6-7) under power-domain-system. With the single
cluster domain of upstream kaanapali.dtsi the firmware rejects almost
every domain state, so this does not show there. In short: we see
silent resets from plain idle, and here they follow the cluster state
rather than SS3.

Symptom: a silent reset after minutes to an hour of idle with the
display off. Nothing in the printk ring or pstore dmesg; the console
ramoops only has "watchdog: CPU7: Watchdog detected hard LOCKUP on cpu 0", and
the watchdog bites before the hardlockup panic is printed.

Keeping SS3 out of runtime idle first seemed to help, but the resets
came back with SS3 never entered at runtime.

An idle-entry recorder (per-CPU ring, records cleaned to PoC around the
PSCI call), read from a RAM dump, shows the lost CPUs entering CPU
retention (0x4) around a cluster 0 power-down (0x01000054) and never
returning from that PSCI call, with IPIs and expired hrtimers pending.
In one case the last CPU, the one requesting the cluster state, did not
return either. Most cluster cycles in the same window were fine, so it
looks like a race between the cluster state and a CPU entering
retention.

Refusing the cluster domain state at runtime: 3 h idle without a reset
(562k cluster-off requests refused). Same kernel with the state allowed:
2 resets in 78 min. Screen-off idle power did not change measurably.

Is the cluster state (and SS3) meant to be used from runtime idle on
these SoCs, or is there a firmware prerequisite we miss?

Not tested on linux-next with Ulf's CPU PM domain series yet. I can run
patches or collect dumps.

Thanks,
Joonhoe Kim

Re: 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 Joonhoe,

Thanks, that is useful. On Glymur (Lenovo Yoga Slim 7x Gen 11) the
pattern is different:

- Plain idle has never reset here: 50,000+ cluster (0x01000054) entries
  and hundreds of SS3 entries without a reset.
- The reset needs a trigger: the first SS3 entry right after a full
  all-core load (a kernel build or stress), 5 out of 5.
- With SS3 removed from the system domain and the cluster state kept,
  3 out of 3 runs of that trigger survived.
- Day to day I run with a cpu_dma_latency constraint of 1500 us, which
  vetoes both the cluster state and SS3 at runtime, and I have not seen
  a runtime reset with it in place.

Glymur has a single CPU idle state, 0x4 retention, which is also the CPU
domain state, so every cluster entry here has its CPUs in retention. I
cannot separate the two the way you did.

A correction to my original report: the min-residency override did not
hold. With no timer pending on any CPU the governor's idle estimate is
effectively unbounded, so the residency check passes, and I had a reset
with it in place. Only removing SS3 from the system domain survived.

Oleg