* Lunar Lake: silent fatal platform resets caused by idle-exit core hang
@ 2026-07-05 21:43 Polina Vishneva
0 siblings, 0 replies; only message in thread
From: Polina Vishneva @ 2026-07-05 21:43 UTC (permalink / raw)
To: Rafael J. Wysocki, Artem Bityutskiy; +Cc: Len Brown, linux-pm, linux-kernel
Hello.
So, I've got frustrated enough with my system cold-resetting every few
days to try to debug the issue, with some success.
TL;DR: cold reset on the cpuidle exit path.
It's *probably* not actually a kernel bug, but I don't know any better
place to submit it (hoping that the Intel folks will take a look).
System:
- Lenovo ThinkPad X1 Carbon Gen 13 (21NS001ACD), BIOS N4BET75W (1.45).
- Intel Core Ultra 7 258V (Lunar Lake), microcode 0x126.
- Kernel 7.1.1, intel_idle in ACPI _CST mode.
- Reproduces even with intel_idle.max_cstate=2, so the enabled
states are only POLL, C1_ACPI and C2_ACPI.
On boot after each crash, the kernel logs:
BERT: [Hardware Error]: Skipped 1 error records
I pulled /sys/firmware/acpi/tables/data/BERT by hand and decoded it with
https://github.com/intel/crashlog.
The region contains a full PMC crashlog (MCA, Punit, UNCORE, PCORE,
PMC, PMC_RST, PMC_TRACE records). iclg summarizes the failure as:
CORE_TIMEOUT.SINGLE_STUCK_TRANSACTION.C898FH
MCA.BANK3.INTERNAL_TIMER_ERROR.MSCOD_E184H
CRASHLOG_REASON.PMC.10H
CRASHLOG_REASON.PUNIT.20004H
RESET_CAUSE.FIRMWARE_GLOBAL_RESET.FW_GBLRST_SCRATCH16
RESET_CAUSE.GLOBAL_RESET.PMC_FW
The important registers (one P-core has captured state):
mca.bank3.status = 0xbe000000e1840400
VAL|UC|EN|MISCV|ADDRV|PCC, MCACOD 0x0400 (internal timer /
retirement watchdog, "three-strike"), MSCOD 0xE184
mca.bank3.addr = mca.bank3.misc = arch_state.lip
= 0xffffffff9471bb3c (kernel text)
super queue: exactly one stuck transaction (cacheline 0xC898F)
pmc_rst: gblrst_cause_0.pmc_fw=1, fw_gblrst_cause_0.scratch16=1,
gblrst_req_0 = pmc_fw|syspwr_flr|pchpwr_flr
The LIP: given that KASLR slide is 2MB-aligned, (lip mod 2M) is an
invariant. Solving over System.map text symbols gives 14 candidates, of
which only one can be related:
cpuidle_enter_state+0xbc
Disassembly:
+0x73 call __x86_indirect_thunk_rax ; target_state->enter()
... sched_clock_idle_wakeup_event / local_clock_noinstr /
sched_idle_set_state
+0xb6 call *pv_ops...irq_enable ; patched to STI at boot
+0xbc test %r14d,%r14d ; <- LIP
So (my best guess) the core had already returned from MWAIT, executed
STI on the idle-exit path, and then stopped retiring instructions. The
retirement watchdog then fires, Punit reports CORE_TIMEOUT, and PMC
firmware pulls a global platform reset.
The question is whether it is something known or rather something
platform-specific that should be reported to Lenovo instead.
I can provide the raw BERT dump, and also I'd be happy to debug/test if
requested.
Best regards,
Polina.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-07-05 21:43 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-05 21:43 Lunar Lake: silent fatal platform resets caused by idle-exit core hang Polina Vishneva
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox