[Laptop 13 Pro] Core Ultra Series 3: CPU clamped to 400 MHz on battery by external PROCHOT# while cool, no charger attached; survives resume, cleared by reboot

[anubisza]

System Model or SKU

Framework Laptop 13 (Intel® Core™ Ultra Series 3)

BIOS Version

03.02 (2026-05-26). fwupdmgr get-updates reports System Firmware as up to date. Firmware versions, from framework_tool --versions: Mainboard Hardware Type: Laptop 13 Pro (Intel Core Ultra Series 3) Revision: MassProduction UEFI BIOS Version: 03.02 Release Date: 05/26/2026 EC Firmware Build version: sakura-3.0.2-cf48815 2026-05-26 04:34:57 lotus@ip-172-26-3-226 Current image: RO PD Controllers Right (01): 1.0.0A (MainFw) Left (23): 1.0.0A (MainFw) Intel Retimers Left: 0xCF (207) Right: 0xCF (207) CSME Firmware Version: 0:21.0.6.1503 HDMI Expansion Card Active Firmware: 106 (3.0.10.06A, MainFw) The EC reports Current image: RO. I'm noting it in case running the RO image is unexpected on this platform. This was captured after the reboot, not during the throttled state.

DIY Edition Information

Memory: 32 GB
Storage: WD_BLACK SN7100 1TB

Port/Peripheral Information

No charger or other USB-C power source was attached at any point during the event. The laptop was running on battery.

Expansion cards, viewed from above. No external peripherals were attached.

• 1: USB-C Expansion Card
• 2: USB-A Expansion Card
• 3: USB-C Expansion Card
• 4: HDMI Expansion Card (firmware 3.0.10.06A)

The HDMI Expansion Card is the only port with a USB-PD partner. Linux enumerates it as UCSI connector 2 (/sys/class/typec/port1, laptop in source role). That connector logs these errors on every boot and on every reseat of the card:

ucsi_acpi USBC000:00: unknown error 256
ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
ucsi_acpi USBC000:00: con2: failed to register partner alt modes (-5)

Standalone Operation

Full System, Standalone mode NOT enabled (normal usage)

Describe the Bug

While on battery, every core was locked at 400 MHz, even under full load. The system was nearly unusable: a keybind that launches a terminal took several seconds to open a window.

The CPU was cool, and nothing on the OS side was limiting frequency. Model-specific registers (MSRs) show that the throttle is an external PROCHOT# assertion, which the CPU honours because BD PROCHOT is enabled:

MSR	Value	Meaning
MSR_CORE_PERF_LIMIT_REASONS (0x64F)	0x8010001	bit 0 PROCHOT active, bit 16 PROCHOT log, bit 27 PL2 log
IA32_THERM_STATUS (0x19C), cpu0	0x883d280c	bit 2 PROCHOT#/FORCEPR# active, bit 3 log; readout 0x3d (TjMax − 61, about 39 °C)
IA32_PACKAGE_THERM_STATUS (0x1B1)	0x883b080c	bit 2 PROCHOT#/FORCEPR# active; thermal status bit 0 clear
MSR_POWER_CTL (0x1FC)	0x8e4005f	bit 0 = 1 (BD PROCHOT enabled)
IA32_PERF_STATUS (0x198)	0x400	ratio 4 (400 MHz)
IA32_HWP_REQUEST (0x774), cpu0	0xc0003505	OS requests max perf 0x35; not the limiter
IA32_HWP_CAPABILITIES (0x771), cpu0	0x10f1635	highest 0x35
MSR_PKG_POWER_LIMIT (0x610)	0x181e0001f8118	PL1 35 W, PL2 60 W (normal)
IA32_MISC_ENABLE (0x1A0)	0x851089	turbo not disabled

The values were identical on cpu0, cpu4 and cpu12, apart from the per-core HWP fields.

Ruled out

• Thermal. The package was at 41 °C, all ACPI thermal zones read 20–42 °C, and thermal_throttle counters were 0. framework_tool --thermal showed:

  F75303_Local: 35 C
  F75303_CPU:   35 C
  Battery:      31 C
  F75303_DDR:   33 C
  PECI:         41 C
  APU Fan:       0 RPM
  

• OS frequency limits. scaling_max_freq equalled cpuinfo_max_freq, intel_pstate was active with max_perf_pct=100 and no_turbo=0, EPP was balance_power, and power-profiles-daemon was on balanced. A busy loop pinned to one core ran at 100% utilisation and still read 400 MHz.
• RAPL. Power limits were the normal 35 / 60 W.
• Battery. framework_tool --power reported a healthy battery:

  Battery Cutoff:     Not cut off
  Charger Status
    AC is:            not connected
    Charger Voltage:  15176mV
    Charger Current:  0mA
    Chg Input Current:384mA
    Battery SoC:      37%
  Battery Status
    AC is:            not connected
    Battery is:       connected
    Battery LFCC:     4826 mAh (Last Full Charge Capacity)
    Battery Capacity: 1744 mAh
    Charge level:     36%
    Battery discharging
  

• Memory pressure. None: 18 GiB available, swap unused.

EC console

framework_tool --console recent shows a clean resume from s2idle. It contains no PROCHOT, thermal, charger or PD fault lines anywhere in the recent log. Excerpt around the resume:

[1763836.049700 lid open]
[1763836.052600 PH S0ix]
[1763836.473400 power state 16 = S0ix->S0, in 0x003f]
[1763836.474700 PH S0ixS0]
[1763836.489400 power state 4 = S0, in 0x003f]
...
[1763837.479100 PL1:35, PL2:60, PL4:80, PSYSPL2:71 updated success]
...
[1763863.594000 Battery 39% (Display 38.4 %) / 4h:30 to empty]

After the resume, battery drain was about 7 W, which is consistent with a CPU clamped to 400 MHz.

Steps To Reproduce

The bug is not reliably reproducible; it has been observed once. The conditions were:

1. On battery, with no charger attached and the HDMI Expansion Card installed.
2. System uptime of about 2 days 20 hours, with 4 s2idle suspend/resume cycles on the same boot.
3. Resume from s2idle (lid open). A game running under Steam/Proton was open at the time.
4. About 11 minutes later, the whole system was noticeably slow, with all cores at 400 MHz. The throttle may have started earlier, at or right after the resume, but it was not being monitored.

What cleared it and what did not

Action	Result
Removing and reinserting the HDMI Expansion Card	Still 400 MHz (UCSI errors logged again on reinsert)
s2idle suspend and resume	Still 400 MHz
Warm reboot	Cleared: about 3.9 GHz under load immediately after, still on battery

The UCSI con2 errors reappear on every boot, including the good boot after the reboot. On their own they are not sufficient to cause the throttle.

Expected Behavior

The EC should not assert PROCHOT# while the CPU is cool, the battery is healthy and no power source is attached. If it asserts PROCHOT# in response to a transient event, it should release it once the event clears, without needing a reboot. At minimum, the reason for the assertion should be logged in the EC console.

Screenshots

No response

Operating System

Omarchy 4.0.4 (Arch Linux based)

Linux Kernel Version

Linux 7.2.5-3-omarchy #1 SMP PREEMPT_DYNAMIC Mon, 14 Sep 2026 19:55:01 +0000 x86_64 GNU/Linux

Additional Context

• This is similar to [Laptop 13 Pro] Core Ultra Series 3: EC latches BD PROCHOT (400 MHz) across reboot; second USB-C charger misdetected as sink (laptop sources 5V/1.5A) #266, with some differences. Here no charger was attached, the trigger appears to be battery operation and/or an s2idle resume, and a warm reboot cleared it. In [Laptop 13 Pro] Core Ultra Series 3: EC latches BD PROCHOT (400 MHz) across reboot; second USB-C charger misdetected as sink (laptop sources 5V/1.5A) #266 the latch survived a reboot and was released by unplugging a misdetected charger. The UCSI unknown error 256 / GET_CABLE_PROPERTY failed signature is the same in both.
• It may also be related to Framework Laptop 16 throttling under load after s2idle sleep on battery #182 (Laptop 16 throttling under load after s2idle on battery).
• The MSRs were read through /dev/cpu/N/msr (the msr kernel module). BD PROCHOT was not disabled at any point, so the values above are the platform's own state.
• If a debug build or extra EC logging would help identify what drives PROCHOT#, I can run it and capture output the next time this happens.