From: Mario Limonciello <mario.limonciello@amd.com>
To: Scrimas <isma.ph@proton.me>, Sandor Nagy <sannnagy@icloud.com>
Cc: linux-pm@vger.kernel.org, platform-driver-x86@vger.kernel.org,
rafael@kernel.org, srinivas.pandruvada@linux.intel.com,
rui.zhang@intel.com
Subject: Re: [BUG] Lunar Lake: 400 MHz after s2idle; PL1 Tau affects reproduction and recovery
Date: Mon, 5 Oct 2026 09:42:26 -0500 [thread overview]
Message-ID: <9159cb48-9b32-4db7-b876-85a48a3bb2a7@amd.com> (raw)
In-Reply-To: <20261005071610.885801-1-isma.ph@proton.me>
On 10/5/26 02:16, Scrimas wrote:
> On Mon, 7 Sep 2026 12:00:37 -0400, Sandor Nagy wrote:
>> My ThinkPad X1 Carbon Gen 13 intermittently resumes from long s2idle
>> suspends with all eight CPUs stuck around 400 MHz.
>
> Same symptom here on a different OEM and a different SKU, so this does
> not look Lenovo-specific:
>
> Samsung Galaxy Book5 Pro 360 (NP960QHA)
> Intel Core Ultra 7 256V (Lunar Lake), BIOS P17ALY.390.260616.03
> Kernel 7.2.9 (CachyOS), intel_pstate active, HWP, s2idle only
> platform_profile=performance, EPP=performance, on battery
> PL1 34 W (MSR and MMIO), Tau 27983872 us (same value as your X1C13)
> thermald not running
>
> I log 60 s of turbostat and the xe GT throttle reasons after every
> resume. Over 2026-10-02..05: 13 resumes after sleeps of 1.5 h or less
> had no 400 MHz samples at all. The one resume after an 8.9 h s2idle
> had all cores at 400 MHz for the first ~9 s of the log (the log
> starts ~1 s after "PM: suspend exit"):
>
> Busy% Bzy_MHz PkgTmp GFXMHz PkgWatt
> 16.37 400 25 400 2.38
> 73.94 400 26 400 3.23
> 49.75 400 27 400 2.87
> ... (6 more samples at 400 MHz, 2.8-3.2 W)
> 40.94 480 28 400 3.04
> 37.83 3557 39 400 10.57
>
> During exactly those seconds, gt0/freq0/throttle/reasons reported
> "pl1", then "none". So the package was being power-limited while
> drawing ~3 W against a 34 W PL1, at 25-28 C. That matches your
> energy-averaging hypothesis.
>
> Ruled out on this machine:
> - ACPI _PPC: booted with processor.ignore_ppc=1, and scaling_max_freq
> stayed at 4.7 GHz during the episode.
> - Thermal: package_throttle_count did not change during the window.
>
> I have not captured MSR 0x19C bits 10-11 yet.
>
> Thanks,
> Scrimas
If this is anything like the similar issue that was reported on some AMD
systems; try unplugging and plugging back in the power adapter while in
the bad state.
If it's already unplugged, plug it in and then unplug it again.
Does that help?
next prev parent reply other threads:[~2026-10-05 14:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 7:16 [BUG] Lunar Lake: 400 MHz after s2idle; PL1 Tau affects reproduction and recovery Scrimas
2026-10-05 14:42 ` Mario Limonciello [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-09-07 16:00 Sandor Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9159cb48-9b32-4db7-b876-85a48a3bb2a7@amd.com \
--to=mario.limonciello@amd.com \
--cc=isma.ph@proton.me \
--cc=linux-pm@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=sannnagy@icloud.com \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox