10 Things I Hate about HP - 对暗影精灵9底层固件的一次浅层探索
Laptop: HP Omen 16-wf0000
CPU: Intel i5 13500HX
GPU: NVIDIA RTX4060 Laptop 8G
Kernel: Linux Zen
System: EndeavourOS Linux
Bootloader: systemd-boot
WM: Hyprland起因
转到Linux前看ProtonDB的时候，天国：拯救2这游戏是Platnium级别的，也没多想，备份了原文件就直接迁移到Linux了。最近才想起来要玩这游戏，虽然老早就在Lutris配置好了GE-Proton-10-8但一直没打开。结果一打开游戏，刚玩没多久，开局的防卫战突然帧数暴跌到大约60左右，本来是能稳定90的，然后进入锁30帧的过场动画之后，帧数再次回升到一个正常水平，本来以为一切正常只是开局着色器渲染而已，但是帧数再次暴跌，这个时候就感觉不对劲了。因为绝地潜兵2也有类似的问题，游玩一段时间之后帧数直接暴跌，CPU的使用率暴降而GPU还在勤勤恳恳跑满。一个游戏出问题还好说，两个游戏出问题我就觉得有问题了，不会是我电脑问题吧？
猜想与排查
1.着色器
这种帧数暴降的问题，尤其是在新游戏上，有大概率都是着色器没有提前编译导致的，尤其是用Lutris打开的时候，没有和Steam一样有一个提前编译的方法。所以首先排查这种情况，尤其是着色器编译风暴，我并不熟悉CryEngine这引擎的特色，但毕竟是从天国：拯救一代就使用的老引擎，在现代环境下有问题是难免，更何况还是Linux + Proton这种中间多了一层转译的环境。但当我在一个场景等待了十分多钟之后，帧数并未好转，而是卡在一个60fps左右的水平，这个时候就感觉不对了，照理来说着色器这个时候早该编译好了，尤其是对于单个场景。在副屏打开btop查看，CPU此时的温度只有七十多度，并且C0-C11都只有60-70的占用率，而GPU则是完全吃满了占用率，这和绝地潜兵2的环境下出现的问题如出一辙。于是怀疑是温度墙的问题。是不是这笔记本有奇怪的降频机制，在75度左右就会降频？
2.软件/内核限制？
（截图不见了，口头描述一下）
CPU：72-79度浮动
GPU：74-76度浮动
CPU功耗：34W
GPU使用率：56%
CPU频率：3.1GHz
显存使用率：7.3G从这个数据可以看出，GPU是基本跑满的一个状态的（56%是因为暂停切屏），而CPU则出现了不正常功耗的水平，34W的功耗基本等于放假。这个时候怀疑是严重的功耗墙引发的CPU瓶颈，比如说在绝地潜兵2中，出现了大量敌人，游戏需要CPU进行大量计算和着色器编译，这个时候固件EC或者Linux内核的默认策略错误判断了当前情况，给CPU施加了一个极低的功耗上限，导致GPU也不得不等待残废的CPU进行编译。首先尝试用throttled这个工具解决：
yay -S throttled
sudo systemctl enable throttled.service
sudo systemctl start throttled.service
reboot重启之后，再次打开游戏，发现毫无卵用。BIOS里面也查看过了，并没有一个所谓的Performance Mode的选项，连沾边的都没有。这个时候奇怪的事情出现： systemctl status throttled.service 显示failed，但是 sudo systemctl enable throttled.service 和 sudo systemctl start throttled.service 又都是成功的。查看可以发现，有一个进程： power-profile activated ，虽然throttled的状态是成功加载（loaded: enabled），但是active: failed。
power-profile就是Linux系统自己的那个功耗控制服务： power-profiles-daemon ，并且由于是系统原生内置，它可能启动顺序更靠前或者启动优先级更高，在throttled之前抢先一步控制了硬件，导致throttled初始化失败。
sudo systemctl stop power-profiles-daemon.service
sudo systemctl disable power-profiles-daemon.service
sudo systemctl mask power-profiles-daemon.service # 屏蔽，防止被其他程序意外唤醒重启。
cynsm sudo systemctl status throttled.service
[sudo] cynsm 的密码：
× throttled.service - Stop Intel throttling
Loaded: loaded (/usr/lib/systemd/system/throttled.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Fri 2025-10-03 23:13:39 CST; 36s ago
Duration: 155ms
Invocation: b18bd933b6a146c2832ec126daa0c7fe
Process: 986 ExecStart=/usr/lib/throttled/throttled.py (code=exited, status=1/FAILURE)
Main PID: 986 (code=exited, status=1/FAILURE)
Mem peak: 27.6M
CPU: 117ms
10月 03 23:13:39 Xynsm systemd[1]: Started Stop Intel throttling.
10月 03 23:13:39 Xynsm throttled.py[986]: [E] Your CPU model is not supported.
10月 03 23:13:39 Xynsm throttled.py[986]: Please open a new issue (https://github.com/erpalma/throttled/issues) specifying:
10月 03 23:13:39 Xynsm throttled.py[986]: - model name
10月 03 23:13:39 Xynsm throttled.py[986]: - cpu family
10月 03 23:13:39 Xynsm throttled.py[986]: - model
10月 03 23:13:39 Xynsm throttled.py[986]: - stepping
10月 03 23:13:39 Xynsm throttled.py[986]: from /proc/cpuinfo.
10月 03 23:13:39 Xynsm systemd[1]: throttled.service: Main process exited, code=exited, status=1/FAILURE
10月 03 23:13:39 Xynsm systemd[1]: throttled.service: Failed with result 'exit-code'.
cynsm ~ throttled不支持我的CPU。CPU太新了，换替代品： intel-undervolt ，据说是可以直接修改CPU的功耗限制（PL1/PL2），所以试试看。它通过直接写入CPU的MSR寄存器来工作，所以理论上兼容所有现代Intel CPU，不会像 throttled 那样有严格的白名单。「存疑」
通过AUR安装完intel-undervolt之后，它不是和throttled一样运行在后台的一个服务，而是直接通过底层配置文件生效的。
sudo nvim /etc/intel-undervolt.conf 内容如下：
# Enable or Disable Triggers (elogind)
# Usage: enable [yes/no]
enable no
# CPU Undervolting
# Usage: undervolt ${index} ${display_name} ${undervolt_value}
# Example: undervolt 2 'CPU Cache' -25.84
undervolt 0 'CPU' 0
undervolt 1 'GPU' 0
undervolt 2 'CPU Cache' 0
undervolt 3 'System Agent' 0
undervolt 4 'Analog I/O' 0
# Power Limits Alteration
# Usage: power ${domain} ${short_power_value} ${long_power_value}
# Power value: ${power}[/${time_window}][:enabled][:disabled]
# Domains: package
# Example: power package 45 35
# Example: power package 45/0.002 35/28
# Example: power package 45/0.002:disabled 35/28:enabled
power package 135 100
# Critical Temperature Offset Alteration
# Usage: tjoffset ${temperature_offset}
# Example: tjoffset -20
# Energy Versus Performance Preference Switch
# Usage: hwphint ${mode} ${algorithm} ${load_hint} ${normal_hint}
# Hints: see energy_performance_available_preferences
# Modes: switch, force
# Load algorithm: load:${capture}:${threshold}
# Power algorithm: power[:${domain}:[gt/lt]:${value}[:[and/or]]...]
# Capture: single, multi
# Threshold: CPU usage threshold
# Domain: RAPL power domain, check with `intel-undervolt measure`
# Example: hwphint force load:single:0.8 performance balance_performance
# Example: hwphint switch power:core:gt:8 performance balance_performance
# Daemon Update Interval
# Usage: interval ${interval_in_milliseconds}
interval 5000
# Daemon Actions
# Usage: daemon action[:option...]
# Actions: undervolt, power, tjoffset
# Options: once
daemon undervolt:once
daemon power
daemon tjoffset手动写入 power package 135 100 ，并且确保 daemon power 是正常开着的。按照注释的示例，这里的单位是瓦（而不是可能的微瓦），所以直接写入135和100就行。保存，并且手动应用： sudo intel-undervolt apply ，启动服务：
sudo systemctl enable intel-undervolt.service
sudo systemctl start intel-undervolt.service在重启前，为了控制变量，同时查看 cpupower 的内容参数：
cynsm cpupower -c
Usage: cpupower [-d|--debug] [-c|--cpu cpulist ] <command> [<args>]
Supported commands are:
frequency-info
frequency-set
idle-info
idle-set
powercap-info
set
info
monitor
help
Not all commands can make use of the -c cpulist option.
Use 'cpupower help <command>' for getting help for above commands.
cynsm cpupower frequency-info
分析 CPU 14：
driver: intel_pstate
以相同硬件频率运行的 CPU：14
需要通过软件协调频率的 CPU：14
energy performance preference: balance_performance
硬件限制：800 MHz - 3.50 GHz
可用的cpufreq调节器：performance powersave
当前政策：频率应在800 MHz和3.50 GHz.
调速器“powersave”可以决定使用哪种速度
在这个范围内。
current CPU frequency: 1.18 GHz (asserted by call to kernel)
boost state support:
支持：是
活跃：是
cynsm cpupower idle-info
CPU 空闲驱动程序：intel_idle
CPU 空闲调节器：menu
分析 CPU 16：
空闲状态数：4
可用的空闲状态： POLL C1_ACPI C2_ACPI C3_ACPI
POLL:
# 后略
cynsm cpupower powercap-info
Driver: intel-rapl
Powercap domain hierarchy:
Zone: package-0
(enabled)
Zone: core
(disabled)
cynsm sudo cpupower info
分析 CPU 17：
性能偏差：6
cynsm ~ cpupower居然是posersave模式，不知道为何。然后 energy performance preference: balance_performance ，EPP的范围是0-15，0是最佳性能，15是最节能，balanced_performance一般来说是一个6-7的平均值，意味着系统时涂在性能和节能之间取得最平衡，然而这对玩大型游戏的时候是毫无必要的。解锁performance： sudo cpupower frequency-set -g performance 。
cynsm sudo nvim /etc/intel-undervolt.conf
cynsm sudo intel-undervolt apply
CPU (0): -0.00 mV
GPU (1): -0.00 mV
CPU Cache (2): -0.00 mV
System Agent (3): -0.00 mV
Analog I/O (4): -0.00 mV
Short term package power: 135 W, 0.002 s, enabled
Long term package power: 100 W, 56.000 s, enabled
cynsm sudo systemctl enable intel-undervolt.service
Created symlink '/etc/systemd/system/multi-user.target.wants/intel-undervolt.service' → '/usr/lib/systemd/system/intel-undervolt.service'.
Created symlink '/etc/systemd/system/suspend.target.wants/intel-undervolt.service' → '/usr/lib/systemd/system/intel-undervolt.service'.
Created symlink '/etc/systemd/system/hibernate.target.wants/intel-undervolt.service' → '/usr/lib/systemd/system/intel-undervolt.service'.
Created symlink '/etc/systemd/system/hybrid-sleep.target.wants/intel-undervolt.service' → '/usr/lib/systemd/system/intel-undervolt.service'.
cynsm sudo systemctl start intel-undervolt.service
cynsm ~ Short term 和 Long term package power 已经分别成功被更改为了 135W 和 100W。
重启。
重启过后 sudo intel-undervolt read ，查看参数：
cynsm systemctl status intel-undervolt.service
○ intel-undervolt.service - Intel Undervolt Service
Loaded: loaded (/usr/lib/systemd/system/intel-undervolt.service; enabled; preset: disabled)
Active: inactive (dead) since Fri 2025-10-03 23:29:08 CST; 4min 15s ago
Invocation: b9baad8b34534bbfa6b698df41eae040
Main PID: 1185 (code=exited, status=0/SUCCESS)
Mem peak: 2.1M
CPU: 16ms
10月 03 23:29:08 Xynsm systemd[1]: Starting Intel Undervolt Service...
10月 03 23:29:08 Xynsm intel-undervolt[1185]: CPU (0): -0.00 mV
10月 03 23:29:08 Xynsm intel-undervolt[1185]: GPU (1): -0.00 mV
10月 03 23:29:08 Xynsm intel-undervolt[1185]: CPU Cache (2): -0.00 mV
10月 03 23:29:08 Xynsm intel-undervolt[1185]: System Agent (3): -0.00 mV
10月 03 23:29:08 Xynsm intel-undervolt[1185]: Analog I/O (4): -0.00 mV
10月 03 23:29:08 Xynsm intel-undervolt[1185]: Short term package power: 135 W, 0.002 s, enabled
10月 03 23:29:08 Xynsm intel-undervolt[1185]: Long term package power: 100 W, 56.000 s, enabled
10月 03 23:29:08 Xynsm systemd[1]: intel-undervolt.service: Deactivated successfully.
10月 03 23:29:08 Xynsm systemd[1]: Finished Intel Undervolt Service.
cynsm ~
日志显示，服务已经成功启动，同时前面设置的Short term和Long term也已经生效了。由于游戏因为Proton这个转译层的存在还是难免会有奇怪的性能问题，所以先开一轮压力测试： stress-ng 。单独再开一个终端打开btop监控进程，另外一个终端跑： stress-ng --cpu 0 --timeout 30s 。
即便设置了intel-undervolt这样的东西，CPU的功耗上限仍然跑在了50W，现在就可以基本可以锁定是写死在固件的功耗墙了，可能是BIOS/UEFI，或者是嵌入式控制器。
那没办法了，BIOS里面也没有一个Performance的选项。要么，更新BIOS，但是好死不死的惠普偏偏只提供了Windows11的.exe，bios更新包。虽然理论上可以走传统的U盘更新，但是我不想为此浪费自己的Ventoy启动盘，思考了一下，记得更新BIOS有一个专门的工具叫作fwupdmgr。试试看，说不定惠普推送了呢？
cynsm sudo fwupdmgr refresh --force
[sudo] cynsm 的密码：
正在更新 lvfs
正在下载... [************************************** ] 还剩不到一分钟…
Successfully downloaded new metadata:
• 11 devices are updatable
• 1 device is supported in the enabled remotes (an update has been published)
cynsm sudo fwupdmgr get-updates
无固件更新可用的设备：
• HP True Vision FHD Camera
• HP UEFI Secure Boot DB
• HP UEFI Secure Boot KEK
• KEK CA
• Netac NVMe SSD 2TB
• PC801 HFS512GEJ9X101N
• PCH SPI Controller
• System Firmware
• UEFI CA
• USB4 host controller
• Windows Production PCA
固件已是最新的设备：
• UEFI dbx
No updates available
cynsm sudo fwupdmgr updates
未找到命令
Use fwupdmgr --help for help
cynsm sudo fwupdmgr update
固件已是最新的设备：
• UEFI dbx
无固件更新可用的设备：
• HP True Vision FHD Camera
• HP UEFI Secure Boot DB
• HP UEFI Secure Boot KEK
• KEK CA
• Netac NVMe SSD 2TB
• PC801 HFS512GEJ9X101N
• PCH SPI Controller
• System Firmware
• UEFI CA
• USB4 host controller
• Windows Production PCA
cynsm ~ 并非推送，惠普似乎根本就没有理会fwupdmgr。那没办法， 深入固件吧。
3.深入固件
1.确认功耗墙来源
先确认当前到底是什么在掐脖子。很多HP机型是支持ACPI的平台挡位的，这个和HP Omen的EC交互有关。看下平台的性能挡位：
cat /sys/firmware/acpi/platform_profile 2>/dev/null
cat /sys/firmware/acpi/platform_profile_choices 2>/dev/null看RAPL电源上限（PL1/PL2）
ls -1 /sys/class/powercap/ 2>/dev/null | grep intel-rapl
grep . /sys/class/powercap/intel-rapl:0/constraint_*_{power_limit_uw,time_window_us} 2>/dev/null一般来说前面已经用intel-undervolt设置过了那这里大概率也会是135W和100W或者至少是其中一个数字，问题应该不会出在这里。或者可以直接读取PL1/PL2的原始值，确认一下有没有被锁：
sudo pacman -S msr-tools powertop linux-tools-meta # Arch/EndeavourOS
sudo modprobe msr
sudo rdmsr -a 0x610 # IA32_PKG_POWER_LIMIT看热限制和节流原因：
sudo turbostat --Summary --interval 1 --quiet --show Busy,CPU%c1,CPU%c6,PkgWatt,CorWatt,GFXWatt,RAMWatt,CoreTmp --num_iterations 5
sudo dmesg | grep -i -E 'rapl|throttle|thermal'运行结果：
cynsm cat /sys/firmware/acpi/platform/profile
[bat error]: '/sys/firmware/acpi/platform/profile': No such file or directory (os error 2)
cynsm cat /sys/firmware/acpi/pm_profile 2>/dev/null
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
│ File: /sys/firmware/acpi/pm_profile
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ 2
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
cynsm cat /sys/firmware/acpi/platform/profile 2>/dev/null
cynsm cat /sys/firmware/acpi/platform_profile 2>/dev/null
cynsm cat /sys/firmware/acpi/platform_profile_choices 2>/dev/null
cynsm cat /sys/firmware/acpi/pm_profile 2>/dev/null
───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
│ File: /sys/firmware/acpi/pm_profile
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 │ 2
───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
cynsm ls -1 /sys/class/powercap/ 2>/dev/null | grep intel-rapl
intel-rapl -> ../../devices/virtual/powercap/intel-rapl
intel-rapl-mmio -> ../../devices/virtual/powercap/intel-rapl-mmio
intel-rapl-mmio:0 -> ../../devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0
intel-rapl:0 -> ../../devices/virtual/powercap/intel-rapl/intel-rapl:0
intel-rapl:0:0 -> ../../devices/virtual/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0
cynsm grep . /sys/class/powercap/intel-rapl:0/constraint_{power_limit_uw,time_windows_us} 2>/dev/null
zsh: no matches found: /sys/class/powercap/intel-rapl:0/constrainttime_windows_us
cynsm grep . /sys/class/powercap/intel-rapl:0/constraint{power_limit_uw,time_windows_us} 2>/dev/null
zsh: no matches found: /sys/class/powercap/intel-rapl:0/constraint_time_windows_us
cynsm cat /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_1_power_limit_uw
───────┬───────────────────────────────────────────────────────────────────────────────────────────────
│ File: /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_1_power_l
│ imit_uw
───────┼───────────────────────────────────────────────────────────────────────────────────────────────
1 │ 130000000
───────┴───────────────────────────────────────────────────────────────────────────────────────────────
cynsm cat /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_0_power_limit_uw
───────┬───────────────────────────────────────────────────────────────────────────────────────────────
│ File: /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_0_power_l
│ imit_uw
───────┼───────────────────────────────────────────────────────────────────────────────────────────────
1 │ 130000000
───────┴───────────────────────────────────────────────────────────────────────────────────────────────
cynsm ^[[200sudo turbostat --Summary --interval 1 --quiet --show Busy,CPU%c1,CPU%c6,PkgWatt,CorWatt,GFXWatt,RAMWatt,CoreTmp --num_iterations 5
zsh: bad pattern: ^[[200sudo
cynsm sudo turbostat --Summary --interval 1 --quiet --show Busy,CPU%c1,CPU%c6,PkgWatt,CorWatt,GFXWatt,RAMWatt,CoreTmp --num_iterations 5
sudo dmesg | grep -i -E 'rapl|throttle|thermal'
[sudo] cynsm 的密码：
deferred Busy
CPU%c1 CPU%c6 CoreTmp PkgWatt CorWatt GFXWatt RAMWatt
8.43 60.87 42 12.60 4.43 0.00 0.00
10.75 64.74 43 12.36 4.29 0.00 0.00
8.97 65.58 42 12.17 4.14 0.00 0.00
10.53 67.08 43 12.29 4.35 0.00 0.00
8.80 65.76 42 12.19 4.19 0.00 0.00
[ 0.074799] CPU0: Thermal monitoring enabled (TM1)
[ 0.092112] thermal_sys: Registered thermal governor 'fair_share'
[ 0.092112] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.092112] thermal_sys: Registered thermal governor 'step_wise'
[ 0.092112] thermal_sys: Registered thermal governor 'user_space'
[ 0.092112] thermal_sys: Registered thermal governor 'power_allocator'
[ 0.946632] thermal LNXTHERM:00: registered as thermal_zone0
[ 0.946635] ACPI: thermal: Thermal Zone [TZ00] (28 C)
[ 0.946682] thermal LNXTHERM:01: registered as thermal_zone1
[ 0.946683] ACPI: thermal: Thermal Zone [TZ02] (10 C)
[ 6.419634] intel_rapl_common: Found RAPL domain package
[ 6.419637] intel_rapl_common: Found RAPL domain core
[ 6.419802] RAPL PMU: API unit is 2^-32 Joules, 2 fixed counters, 655360 ms ovfl timer
[ 6.419806] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[ 6.419808] RAPL PMU: hw unit of domain package 2^-14 Joules
[ 6.428432] intel_rapl_common: Found RAPL domain package
cynsm sudo modprobe msr
cynsm sudo rdmsr -a 0x610
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320
42843800df8320从输出可以得出以下几点结论：
1.这台机器根本就没有 ACPI platform_profile 接口。搞了半天 power-profiles-daemon 毫无用武之地
2.RAPL 的PL1/PL2的确不是限制来源：intel-rapl-mmio显示PL1和PL2都是130W，MSR 0x610也一样，说明不是被Linux的RAPL卡在了50W。
结合在游戏内72°C左右就掉功率，基本可以确定是HP的EC/平台策略在控制温控功耗了，且有Dynamic Boost的时候优先GPU，CPU则是被平台功耗或者温度策略压制，而不是RAPL。
2.验证、争取更高的CPU持续功耗
首先需要做好最坏的打算：万一惠普就是没有给Linux提供厂商接口怎么办？目前看来唯一可解的方法就是用Windows的Omen Gaming Hub将性能挡位持久化到EC，再回到Linux，但这显然是给强迫症的、没有办法的办法。先试试其他方法。
有那么几个思路可以试试看：
1.把CPU的调频和HWP策略彻底切换到性能优先，避免软件侧再来添堵。
2.寻找HP的WMI/EC控制接口，如果有的话就可以直接切换模式了，这个理论上是最佳选择。
3.搞个压测对比，测试仅CPU满载和GPU满载下GPU限制功耗，验证是不是平台总功耗分配和75°C左右的温度墙所导致。
4.降低GPU PL给CPU腾出性能预算，或者干脆用thermald尝试清75°C的提前热阈。
1.HWP EPP + governor
先确保 intel_pstate/HWP在性能开关上，避免被EPP限制：
# 查看当前驱动与 governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 2>/dev/null
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2>/dev/null
# 若有 EPP 接口，切到 performance
for f in /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference; do
[ -f "$f" ] && echo performance | sudo tee "$f"
done
sudo x86_energy_perf_policy performance
for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
[ -f "$f" ] && echo performance | sudo tee "$f"
done
# 验证
head -n1 /sys/devices/system/cpu/cpu0/cpufreq/{scaling_driver,scaling_governor} 2>/dev/null然后用stress-ng简单粗暴拉满CPU，再用turbostat（或者btop也行反正）看包功耗峰值
# 以 30 秒 CPU 压测为例，按你逻辑核数量调整 -c
sudo turbostat --Summary --interval 1 --quiet --show Busy,CPU%c1,CPU%c6,PkgWatt,CoreTmp --num_iterations 3 &
TS_PID=$!
sleep 1
stress-ng -c $(nproc) -t 30s
wait $TS_PID 2>/dev/null || true结果：
cynsm head -n1 /sys/devices/system/cpu/cpu0/cpufreq/{scaling_driver,scaling_governor} 2>/dev/null
==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver <==
intel_pstate
==> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor <==
performance
cynsm sudo turbostat --Summary --interval 1 --quiet --show Busy,CPU%c1,CPU%c6,PkgWatt,CoreTmp --num_iterations 3 &
TS_PID=$!
sleep 1
stress-ng -c $(nproc) -t 30s
wait $TS_PID 2>/dev/null || true
[1] 42734
[sudo] cynsm 的密码：
[1] + 42734 suspended (tty input) sudo turbostat --Summary --interval 1 --quiet --show --num_iterations 3
stress-ng: info: [42739] setting to a 30 secs run per stressor
stress-ng: info: [42739] dispatching hogs: 20 cpu
^Cstress-ng: info: [42739] stopping 20 stressors
stress-ng: info: [42739] skipped: 0
stress-ng: info: [42739] passed: 20: cpu (20)
stress-ng: info: [42739] failed: 0
stress-ng: info: [42739] metrics untrustworthy: 0
stress-ng: info: [42739] successful run completed in 4.10 secs
[sudo] cynsm 的密码：
[1] + 42734 suspended (tty input) sudo turbostat --Summary --interval 1 --quiet --show --num_iterations 3
^C% cynsm sudo turbostat --Summary --interval 1 --quiet --show Busy,CPU%c1,CPU%c6,PkgWatt,CoreTmp --num_iterations 3 &
[2] 42953
cynsm ~ [sudo] cynsm 的密码： in zsh at 00:42:36
[2] + 42953 suspended (tty input) sudo turbostat --Summary --interval 1 --quiet --show --num_iterations 3
cynsm stress-ng --cpu 0 --timeout 30s
\stress-ng: info: [43078] setting to a 30 secs run per stressor
stress-ng: info: [43078] dispatching hogs: 20 cpu stress-ng: info: [43078] skipped: 0
stress-ng: info: [43078] passed: 20: cpu (20)
stress-ng: info: [43078] failed: 0
stress-ng: info: [43078] metrics untrustworthy: 0
stress-ng: info: [43078] successful run completed in 30.01 secs观察的是btop结果，这里turbostat似乎出了点问题.jpg。btop内显示，上限仍然撞50W的功耗墙。
2.查HP WMI/EC有没有暴露性能/风扇接口
这一步如果成功，往往就是一锤定音了，如果有在Linux下暴露，相当于是适配性最好的原厂接口。
ls -d /sys/devices/platform/hp-* 2>/dev/null
grep -R . /sys/devices/platform/hp-* 2>/dev/null | head -n 200顺便去AUR找找有没有社区为OMEN专门开发的专用工具，比如给ASUS系列开发的一样：
yay -Ss omen | grep -i -E 'control|fan|profile'ls -d /sys/devices/platform/hp-* 2>/dev/null
/sys/devices/platform/hp-wmi
cynsm grep -R ./sys/devices/platform/hp-* 2>/dev/null | head -n 200
zsh: no matches found: ./sys/devices/platform/hp-*AUR并没有返回任何关于OMEN工具的信息。
3.验证是不是平台总功耗分配和72°C的提前热强在作怪
如果CPU+GPU 同时负载（例如跑个轻度 3D + cpu 压测），若 CPU 立刻掉到 35–40W，而 GPU 满载，则高度吻合 Dynamic Boost + EC 策略。可以试着暂时把GPU的功耗上限往下压一点。
nvidia-smi --query-gpu=name,power.limit,power.min_limit,power.max_limit --format=csv
sudo nvidia-smi -pl 90很可惜：
cynsm nvidia-smi --query-gpu=name,power.limit,power.min_limit,power.max_limit --format=csv
name, power.limit [W], power.min_limit [W], power.max_limit [W]
NVIDIA GeForce RTX 4060 Laptop GPU, [N/A], 5.00 W, 140.00 W
cynsm sudo nvidia-smi -pl 70
[sudo] cynsm 的密码：
Changing power management limit is not supported for GPU: 00000000:01:00.0.
Treating as warning and moving on.
All done.不支持。
4.尝试缓解72°C撞线？thermald与TCC偏移
systemctl status thermald --no-pager
sudo pacman -S thermald
sudo systemctl enable --now thermald读一下温度相关MSR：
sudo rdmsr -a 0x1a2输出：
cynsm systemctl status thermald --no-pager
● thermald.service - Thermal Daemon Service
Loaded: loaded (/usr/lib/systemd/system/thermald.service; enabled; preset: disabled)
Active: active (running) since Sat 2025-10-04 00:46:11 CST; 2s ago
Invocation: c3cc7e42831a418498ee9880aaf45536
Main PID: 44870 (thermald)
Tasks: 6 (limit: 18516)
Memory: 3M (peak: 3M)
CPU: 12ms
CGroup: /system.slice/thermald.service
└─44870 /usr/bin/thermald --systemd --dbus-enable --adaptive
10月 04 00:46:11 Xynsm systemd[1]: Starting Thermal Daemon Service...
10月 04 00:46:11 Xynsm thermald[44870]: 32 CPUID levels; family:model:stepping 0x6:bf:2 (6:191:2)
10月 04 00:46:11 Xynsm thermald[44870]: 32 CPUID levels; family:model:stepping 0x6:bf:2 (6:191:2)
10月 04 00:46:11 Xynsm thermald[44870]: Polling mode is enabled: 4
10月 04 00:46:11 Xynsm systemd[1]: Started Thermal Daemon Service.
cynsm sudo rdmsr -a 0x1a2
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000
83640000很可惜，上面四个方案全部失败：
intel_pstate + performance, EPP这边没效果。
RAPL不是限制源头。
GPU不支持改PL。
MSR 0x1A2显示TCC目标温度100°C，72°C掉瓦不是PROCHOT正常触发，更像是HP的EC/平台策略提早限制。
thermald已经运行了，但是没法改变EC侧的72°C提前墙。
现在还有两条路能走：
1.排除其他节能服务
systemctl status tlp --no-pager || true
systemctl status auto-cpufreq --no-pager || true2.关掉BD PROCHOT。
# 读当前 IA32_MISC_ENABLE（0x1FC），看 BD PROCHOT 位状态
sudo rdmsr -p 0 0x1fc
# 关闭 BD PROCHOT（清 bit 18），仅测试用；会对所有核写同一值
# 保留其它位，只清掉第 18 位
sudo sh -c 'VAL=$(rdmsr -p 0 0x1fc); printf -v H "0x%s" "$VAL"; printf -v NEW "0x%X" $(( H & ~0x00040000 )); wrmsr -a 0x1fc "$NEW"; echo "Old=$H New=$NEW"'
# 压测 30s 并观察是否越过 50W
sudo turbostat --interval 1 --num_iterations 30 --show Busy,CPU%c1,CPU%c6,PkgWatt,CoreTmp什么是BD PROCHOT？简单来说，就是检测当温度到达一定阈值的时候就自动发出指令降频。关掉它，CPU就不会被EC提前拉闸，往往能突破性能瓶颈。只不过极端情况下机身或者热点温度会上升，只在压测时作为试验，实时盯温度，确保风扇压得住，转的上去。
同样，需要再次确认RAPL约束（之前打错了，time_window_us多了个s变成了time_windows_us）：
grep . /sys/devices/virtual/powercap/intel-rapl:0/constraint_*_{power_limit_uw,time_window_us} 2>/dev/null
grep . /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_*_{power_limit_uw,time_window_us} 2>/dev/null cynsm ls -la /sys/devices/platform/hp-wmi
sudo dmesg | grep -i -E 'hp[-_ ]wmi|omen|hp bios' || true
modinfo hp_wmi | sed -n '1,120p'
.rw-r--r-- 4.1k root 4 10月 00:49 als
.r--r--r-- 4.1k root 4 10月 00:49 display
.r--r--r-- 4.1k root 4 10月 00:49 dock
lrwxrwxrwx - root 4 10月 00:49 driver -> ../../../bus/platform/drivers/hp-wmi
.rw-r--r-- 4.1k root 4 10月 00:49 driver_override
.r--r--r-- 4.1k root 4 10月 00:49 hddtemp
drwxr-xr-x - root 4 10月 00:49 hwmon
.r--r--r-- 4.1k root 4 10月 00:49 modalias
.rw-r--r-- 4.1k root 4 10月 00:49 postcode
drwxr-xr-x - root 4 10月 00:49 power
lrwxrwxrwx - root 4 10月 00:49 subsystem -> ../../../bus/platform
.r--r--r-- 4.1k root 4 10月 00:49 tablet
.rw-r--r-- 4.1k root 4 10月 00:49 uevent
[ 0.000000] # 省略
[ 6.385072] input: HP WMI hotkeys as /devices/virtual/input/input31
[ 6.393279] hp_wmi: query 0x4c returned error 0x6
filename: /lib/modules/6.16.8-zen3-1-zen/kernel/drivers/platform/x86/hp/hp-wmi.ko.zst
alias: wmi:5FB7F034-2C63-45E9-BE91-3D44E2C707E4
alias: # 省略
license: GPL
description: HP laptop WMI driver
author: Matthew Garrett mjg59@srcf.ucam.org
srcversion: 331B538BDB55A1ABCE6EC24
depends: rfkill,platform_profile,sparse-keymap,wmi
intree: Y
name: hp_wmi
retpoline: Y
vermagic: 6.16.8-zen3-1-zen SMP preempt mod_unload
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: # 略
sig_hashalgo: sha512
signature: # 略
cynsm systemctl status tlp --no-pager || true
Unit tlp.service could not be found.
cynsm systemctl status auto-cpufreq --no-pager || true
Unit auto-cpufreq.service could not be found.
cynsm grep . /sys/devices/virtual/powercap/intel-rapl:0/constraint_{power_limit_uw,time_window_us} 2>/dev/null
grep . /sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint{power_limit_uw,time_window_us} 2>/dev/null
zsh: no matches found: /sys/devices/virtual/powercap/intel-rapl:0/constraint*_power_limit_uw
/sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_0_power_limit_uw:55000000
/sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_1_power_limit_uw:130000000
/sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_2_power_limit_uw:200000000
/sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_0_time_window_us:31981568
/sys/devices/virtual/powercap/intel-rapl-mmio/intel-rapl-mmio:0/constraint_1_time_window_us:2440从输出当中可以看到constraint_0被压到了55W：EC/固件把RAPL PL1通过MMIO接口压到了55W，PL2仍然是130W。怀疑有可能是PL1被快速回写导致。干脆直接一步到位，关闭BD PROCHOT测试。
令人失望的是，关闭了BD PROCHOT之后还是有问题。赶紧重新打开BD PROCHOT
sudo sh -c 'VAL=$(rdmsr -p 0 0x1fc); printf -v H "0x%s" "$VAL"; printf -v NEW "0x%X" $(( H | 0x00040000 )); wrmsr -a 0x1fc "$NEW"; echo "BD PROCHOT re-enabled. New value: $NEW"'这个时候我就觉得不对劲了，不对啊。我又不是所有游戏都跑不起来，为什么只有天国拯救2和绝地潜兵2有问题？虽然这俩游戏都是CPU密集型，但是不至于卡成这个样子吧？无人深空所有的星球生成的数学运算都在本地CPU进行，也没见卡顿啊？
Paradigm Shift
看了看ProtonDB的天国拯救2的介绍，大家都是用的Proton 9.0-4，就我用的GE-Proton 10-8。我还注意到一个事情，我是Lutris启动的学习版，没有提前编译着色器，过场动画强制锁定30fps。然后过场动画完毕之后，明明温度还是在70以上，但是功率是四十多瓦，而且帧数可以维持相当一段时间，然后才掉下来，这是不是说明其实是我天国拯救2的配置不对和其本身的问题？因为现在有问题的游戏就天国拯救2和绝地潜兵2，其他游戏毫无掉帧问题，就算是消逝的光芒2这种也是一样。而CryEngine，前面说过了，毕竟是老引擎了，出点问题也不奇怪。
说干就干。先在Steam打开非Steam游戏，找到本地天国拯救2的地址，然后给上Proton 9.0-4这个大家都在推荐的版本，在Steam启动。帧数稳定。
至此破案，搞了半天是Proton版本的问题，彻底的小题大做。虽然这无法改变惠普这个奇葩硬件策略的问题。
题外话：为什么无人深空等游戏没问题？
首先无人深空算是例外中的一个例外。不只是说他免费更新九年的奇迹，更是因为它是为数不多出了名的CPU密集游戏，而且也是为数不多Linux/Proton支持的典范：他们原生支持Vulkan渲染器。通过Steam运行无人深空，有大概率会下载到一个提及巨大的、预编译的着色器缓存包，这三点加起来，只要配置足够基本不存在卡顿的可能（虽然这游戏本体优化很烂哈哈）。
堕落之主2023，Lords of the Fallen，这游戏用了虚幻5，在第一次启动的时候是有很久的着色器编译的。虚幻引擎有一个非常成熟的「管线状态对象缓存」系统，这就是导致第一次启动游戏的时候那个漫长着色器编译的原因。而且UE5使用了Nanite和Lumen技术，它们的数据流式加载非常智能，可以平滑、持续地从硬盘加载将要看到的内容，等等。基本上现代游戏都有专门为多核CPU做优化甚至就是为了它们设计的，虽然天国拯救2是2025年初的游戏，而且肯定不能否认这么多年，CryEngine引擎肯定也更新了，但毕竟还是一个相对……「边缘」的引擎，出现性能问题也难免。ProtonDB的天国拯救2的Platnium评级是有特定条件的：使用Proton Experimental。这引擎的一些历史遗留导致它可能有一些东西需要更稳定的Proton版本进行处理，而不是更激进的GE-Proton-10-8。
至于绝地潜兵2那个是箭头社的问题
10 Things I Hate about HP - 对暗影精灵9底层固件的一次浅层探索
http://localhost:50392/archives/10-things-i-hate-about-hp---dui-an-ying-jing-ling-9di-ceng-gu-jian-de-yi-ci-qian-ceng-tan-suo