### Summary

On an ASUS Zenbook S14 UX5406AA (Intel Core Ultra 9 386H, Panther Lake) running
Omarchy, the whole desktop becomes extremely laggy. The CPU is stuck at its 400 MHz
minimum on every core, even under a deliberate all-core load. It has been pinned at
400 MHz since boot.

Root cause is confirmed from the CPU's own MSRs: an **external BD PROCHOT is
asserted**, while the CPU's own thermal PROCHOT bit is NOT set. So the platform/EC is
pulling the PROCHOT line. This is not heat, not a RAPL power limit, not the cpufreq
governor, and not thermald. I am filing here mainly to ask for the kernel A/B angle
(below), since I am currently on the custom `linux-ptl-audio` kernel.

### System

- OS: Omarchy (Arch-based), limine + UKI
- Booted kernel: `7.1.0-rc2-5-ptl-audio-dirty` (custom: torvalds v7.1-rc2 + SOF audio patches)
- Also installed: `linux 7.0.9.arch2-1`, `linux-mainline-panther-lake 7.0rc4-2`
- Board: ASUS Zenbook S14 UX5406AA, BIOS UX5406AA.300
- CPU: Intel Core Ultra 9 386H, 16 logical CPUs, 400 MHz min / 5.0 GHz max

### Confirmed root cause (read directly from MSRs)

```
PERF_LIMIT_REASONS (0x64F) = 0x10001   -> status bit: PROCHOT, log bit: PROCHOT
BD_PROCHOT_enable  (0x1FC bit0) = 1    -> external PROCHOT assertion is enabled
THERM_STATUS       (0x19C)            -> prochot_now=0, prochot_log=0, pwrlimit=0
                                          (CPU's OWN thermal PROCHOT is NOT asserted)
HWP_CAP            (0x771)            -> highest=54, lowest=1
HWP_REQUEST        (0x774)            -> min=5, max=54, epp=0 (per-core max 54/39/35)
                                          (the OS requests FULL speed; it is overridden)
```

The cores request maximum performance, but an external BD PROCHOT assertion forces
them to the 400 MHz floor. The CPU is not thermally PROCHOT-ing itself, so the signal
comes from the platform (EC / charger / a non-CPU sensor wired to PROCHOT).

### Corroborating measurements (everything else is healthy)

turbostat under a 4-core busy loop (one core at 99% busy):

```
Busy%   Bzy_MHz   PkgTmp   PkgWatt
99.5    400       43       2.5
```

```
Package temp 43C, core temps 39-42C, NVMe ~36C
RAPL limits: PL1 64W, PL2 175W, PL3/PSys 200W (drawing only ~2.5W)
thermal_throttle/core_throttle_count    = 0
thermal_throttle/package_throttle_count = 0
governor=powersave  EPP=performance  platform_profile=performance
intel_pstate: status=active  no_turbo=0  max_perf_pct=100
AC0/online=1   BAT0/status=Full   (also drawing over USB-C PD: USBC000:002 online)
highest scaling_cur_freq seen this entire boot = 400029 kHz (stuck since boot)
```

### Already ruled out

- Thermal throttling: temps 39-44C, zero throttle counters, CPU thermal-PROCHOT bit clear.
- Power limit (RAPL): drawing ~2.5W of a 64W PL1.
- Governor / pstate config: all performance, max_perf_pct=100, turbo enabled.
- thermald: stopping `thermald.service` did NOT change the clamp.
- ASUS throttle policy / turbo: cycling `throttle_thermal_policy` and `no_turbo` did NOT help.
- Memory/swap/disk: 16Gi RAM free, 0 swap used, disk 18%.

### Most likely external sources of the BD PROCHOT (in order)

1. USB-C charger / PD negotiation (on USB-C PD with battery Full).
2. Stuck/buggy EC firmware (plausible on this bleeding-edge Panther Lake board).
3. A non-CPU sensor (VRM, charger IC, battery) wired to PROCHOT misreporting.

### The Omarchy-relevant question (kernel A/B)

`linux-ptl-audio` differs from stock only by SOF/ASoC SoundWire machine-matching
patches, all under `sound/soc/`, which cannot affect intel_pstate, HWP, or PROCHOT.
BD PROCHOT is asserted by the platform and merely reported by the kernel, so the audio
patches are not a credible suspect. However, the custom kernel's **base** is torvalds
v7.1-rc2, vs Arch's `linux` 7.0.9, so a base-kernel pstate/HWP difference for Panther
Lake is still worth ruling out.

Has anyone seen Core Ultra (Panther Lake) machines on Omarchy get pinned to minimum
frequency by BD PROCHOT, and does the shipped `linux-mainline-panther-lake` behave
differently from a mainline v7.1-rc base here?

### Suggested next diagnostics

1. Swap power source (proper ASUS barrel / high-wattage USB-C PD), re-read `0x64F`.
2. Hard EC reset: full shutdown, unplug all power, hold power button ~40s, reboot.
3. A/B kernel test: boot stock `linux 7.0.9.arch2-1`, re-read `0x64F` / `0x1FC` under load.
4. Last resort (disables a safety control): clear bit0 of MSR `0x1FC` (BD_PROCHOT
   enable) on all cores; if the clock jumps, that is 100% confirmation. Re-enabled on reboot.

### How to reproduce the read (root + msr module)

```bash
sudo modprobe msr
sudo rdmsr -a 0x64f ; sudo rdmsr 0x1fc -f 0:0 ; sudo rdmsr 0x19c
sudo turbostat --show Busy%,Bzy_MHz,PkgWatt,PkgTmp --interval 1 --num_iterations 3
```

Caveat: I confirmed causation by reading `PERF_LIMIT_REASONS = PROCHOT`, not by
toggling BD PROCHOT live, and I have not yet verified stock-kernel behavior, so the
base-kernel angle is formally still open even though the mechanism points off-CPU.