* Re: Bug Report: intel_idle: no model entry for Wildcat Lake, falls back to ACPI _CST
2026-08-05 13:53 ` Bug Report: intel_idle: no model entry for Wildcat Lake, falls back to ACPI _CST Artem Bityutskiy
@ 2026-08-05 14:34 ` Karan Shukla
0 siblings, 0 replies; 2+ messages in thread
From: Karan Shukla @ 2026-08-05 14:34 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-pm, rafael, lenb
Hi Artem,
On Wed, 2026-08-05 at 16:53 +0300, Artem Bityutskiy wrote:
> I did not measure Wildcat Lake (WCL), only Panther Lake (PTL).
No problem, thanks for the context.
> Yes, we internally discussed to just use Pather Lake (PTL) values, but
> we figured there may be differences in firmware, and I was not
> comfortable using PTL values for WCL without measuring them.
That makes sense, I originally thought about using the PTL values as well.
I'm happy to help with any latency measurements that would be useful for
a potential patch. I have the WCL hardware in daily use, so I can run
whatever is needed on it. I see wult is the tool for this, so I'm glad
to set it up and run whichever configuration you'd want, and to send the
results in whatever format is most useful to you.
Karan
(For posterity, I'm including my original email as plain text below so
it isn't lost from the thread. The first send went out as HTML and
didn't make it to the list archive.)
--
Hi,
This is a bug report, not a patch. I've been debugging a Dell XPS 13 on
Fedora 44 (kernel 7.1.6) and working through a few processor state
issues. In this case I was able to determine that intel_idle has no
entry for Wildcat Lake, though Panther Lake was added earlier this year.
I can't verify what the correct C-state values for this silicon are, so
I wanted to send a report rather than guess at them.
On a Dell XPS 13 (DX13260) with an Intel Core 5 320 (family 6, model 213
/ 0xD5, stepping 1), intel_idle loads but finds no model match and falls
back to enumerating states from ACPI _CST.
$ cat /sys/devices/system/cpu/cpuidle/current_driver
intel_idle
$ for s in /sys/devices/system/cpu/cpu0/cpuidle/state*/; do \
echo "$(cat $s/name) $(cat $s/desc)"; done
POLL -> "CPUIDLE CORE POLL IDLE"
C1_ACPI -> "ACPI FFH MWAIT 0x0"
C2_ACPI -> "ACPI FFH MWAIT 0x21"
C3_ACPI -> "ACPI FFH MWAIT 0x60"
The _ACPI suffixes and "ACPI FFH MWAIT" descriptions are the fallback
path. No intel_idle module parameters are set (no_acpi=N, use_acpi=N,
no_native=N, states_off=0, max_cstate=9).
arch/x86/include/asm/intel-family.h has the model:
#define INTEL_WILDCATLAKE_L IFM(6, 0xD5)
drivers/idle/intel_idle.c's match table does not. As of the current
mainline, it ends at INTEL_PANTHERLAKE_L.
INTEL_PANTHERLAKE_R (0xE5) is also present in intel-family.h and also
absent from intel_idle.
Comparing what ACPI _CST gives us here against ptl_cstates, the nearest
existing table: C1 matches exactly, and C6S carries the same MWAIT 0x21
hint with somewhat different timings (127us exit latency and 381us
target residency here, against 300us and 300us). Two differences do look
like they matter:
1. C1E (MWAIT 0x01, 10us/10us in ptl_cstates) is not exposed at all.
2. C10 is present with the correct MWAIT 0x60 hint, but is advertised
with an exit latency of 1048us against ptl_cstates' 370us, and a
target residency of 3144us against 2500us. So the governor reaches
for it later, and PM QoS constraints exclude it more readily.
The MWAIT hints themselves are correct, and C10 is being entered heavily
already, so this is not a case of a state being unreachable. Over ~2h of
uptime on cpu0:
C1_ACPI: usage 4093039, time 455056615 us
C2_ACPI: usage 1739573, time 867104684 us
C3_ACPI: usage 701765, time 1022082936 us
C2_ACPI averages ~498us per entry, well under either C10 target
residency, so relaxing 3144 -> 2500 would promote very little of it. The
C1E gap is probably the larger of the two.
Request
Could Wildcat Lake (0xD5) get an entry with the correct table for the
silicon? If it is a Panther Lake derivative that can reuse ptl_cstates,
that would be a one-liner, but I have no way to confirm that from here
and didn't want to guess at exit latencies.
I'm happy to test a patch on this hardware and report residency numbers
back.
Context: this is the fourth piece of Intel tooling I've hit that doesn't
know model 0xD5. intel_lpmd rejects it outright ("Platform not supported
yet", filed as intel/intel-lpmd#123 with a fix proposed in #124),
thermald reports an unsupported CPU model, and turbostat cannot read
package C state residency on it, which makes PC10 unmeasurable and in
turn makes S0ix debugging on this platform harder than it needs to be.
On the intel_lpmd side I opened the PR mainly for visibility, and I'm
running the updated daemon on the device with no issues.
System details
Dell XPS 13 DX13260, BIOS 1.3.0 (2026-06-25)
Intel Core 5 320, family 6 model 213 (0xD5) stepping 1
Fedora Linux 44, kernel 7.1.6-201.fc44.x86_64
CONFIG_INTEL_IDLE=y, CONFIG_ACPI_PROCESSOR_CSTATE=y
Investigation was assisted by an AI coding assistant (Claude,
claude-opus-5) per Documentation/process/coding-assistants.rst. All
measurements above were taken on the machine and are reproducible with
the commands shown. No patch is proposed and no code is included.
Thanks,
Karan Shukla
On Wed, 5 Aug 2026 at 09:53, Artem Bityutskiy
<artem.bityutskiy@linux.intel.com> wrote:
>
> Hi,
>
> On Wed, 2026-08-05 at 09:31 -0400, Karan Shukla wrote:
> > Hi,
> >
> > In this case I was able to determine that intel_idle has no entry for Wildcat Lake, though Panther Lake was added earlier this year.
>
> Just historical context:
>
> I submitted Panther Lake patches.
>
> I did not measure Wildcat Lake (WCL), only Panther Lake (PTL). Yes,
> we internally discussed to just use Pather Lake (PTL) values, but we
> figured there may be differences in firmware, and I was not
> comfortable using PTL values for WCL without measuring them.
>
>
> Artem.
^ permalink raw reply [flat|nested] 2+ messages in thread