[SOLVED] HP OMEN Max 16 (RTX 5080) GPU stuck at 80W

Graphics / Linux Linux
1

Referring to

Big thanks to u/izzieboopers, who solved this properly and made a kernel module for it:

https://github.com/IzzieBoopers/5080-Unlock_Linux/

The issue was exactly what was suspected: the BIOS needs the OMEN-specific WMI boost / GPU thermal commands before nvidia-powerd can actually raise the GPU power budget. Without that, the GPU stays capped around 80W even though the hardware can do much more.

u/izzieboopers wrote a small kernel module, omen_wmi_boost, which sends the missing WMI calls and exposes the boost state through sysfs.

With this fix, the full 175W GPU power target is possible on the OMEN Max 16 RTX 5080, instead of being stuck at the 80W Linux cap.

Another user also confirmed that this is not only useful for the OMEN Max 16 / board 8D41:

This fix is working also for board HP Omen 14-fb0xxx (board 8C58). I was capped at 50w even with nvidia-powerd on, with your service installed now I get the full 65 watts.

I’m on CachyOS, kernel:

7.0.9-1-cachyos

The important CachyOS-specific correction is that the CachyOS kernel is built with Clang, so the module must also be built with Clang/LLVM. Plain GCC build/install can fail.

These are the steps that worked for me.

Install dependencies:

sudo pacman -S linux-cachyos-headers clang lld llvm

Clone the repo:

git clone https://github.com/IzzieBoopers/5080-Unlock_Linux.git
cd ~/5080-Unlock_Linux

Run the installer with Clang/LLVM:

sudo env LLVM=1 CC=clang LD=ld.lld ./install.sh

Load the module:

sudo modprobe omen_wmi_boost

Enable performance mode:

sudo modprobe -r omen_wmi_boost
sudo modprobe omen_wmi_boost boot_mode=performance auto_boost=1 persist=1

Verify that it loaded:

lsmod | grep omen
modinfo omen_wmi_boost

Check the module state:

ls -la /sys/kernel/omen_wmi_boost
cat /sys/kernel/omen_wmi_boost/gpu_state
cat /sys/kernel/omen_wmi_boost/last_error

For testing with Unigine Superposition, make sure it runs on the NVIDIA GPU and not the iGPU:

prime-run ./Superposition

Monitor power/clocks:

nvtop
nvidia-smi
watch -n1 'nvidia-smi --query-gpu=power.draw,power.limit,clocks.gr,clocks.mem,pstate,temperature.gpu --format=csv'

After switching to performance mode, idle usage was still only around 6W for me in nvtop, probably because NVIDIA PRIME/offload still lets the dGPU idle low. So performance mode does not seem to force the GPU to pull high wattage constantly; it mainly enables the higher boost path under load.

So the actual solution is: install omen_wmi_boost from u/izzieboopers’ repo, and on CachyOS run the installer with:

sudo env LLVM=1 CC=clang LD=ld.lld ./install.sh

Again, huge thanks to u/izzieboopers for solving this and publishing the fix.

2

First time posting to the Forums, but here goes:

The project has now received a substantial update.

The original version handled the missing HP WMI performance-state calls required to release the NVIDIA GPU from the Linux 80 W cap. The current main branch keeps that functionality, but now also includes a GPU-aware cooling controller and additional safety checks intended for sustained GPU workloads.

Updated repository:

The new version adds:

  • Automatic GPU fan control using a configurable temperature curve

  • Workload detection based on GPU utilization, clock speed, and temperature

  • Additional cooling bias during long-running workloads

  • Cooldown handling after a workload finishes

  • Automatic return to firmware fan control while idle

  • High-temperature warnings

  • Automatic unlock disablement if critical temperatures persist

  • Recovery and verification after kernel updates

  • Stricter board validation before the module is allowed to load

  • Improved install, uninstall, dry-run, and hardware-test paths

Although the default cooling profile was developed and tested primarily around sustained AI inference workloads, the controller is not AI-specific.

It responds to GPU activity and temperature, not to the application generating the load. Games, rendering programs, video encoders, simulation tools, compute applications, Blender, CUDA workloads, Vulkan workloads, and other GPU-heavy software can all trigger the same cooling behavior.

The expected benefit for gaming and other non-AI workloads is improved thermal control during sustained GPU load. Depending on the workload and the laptop’s cooling conditions, this may help the GPU maintain higher clocks and its enabled power target for longer instead of becoming limited by rising temperature or delayed fan response.

This should be most noticeable during:

  • Long gaming sessions

  • GPU-heavy scenes with sustained utilization

  • Shader compilation or asset-processing workloads

  • Blender or other GPU rendering

  • CUDA and general-purpose GPU compute

  • Video encoding and transcoding

  • Simulation and engineering workloads

  • Any task that keeps GPU utilization, clocks, or temperature elevated

It does not guarantee higher frame rates or faster completion times in every workload. Short jobs, CPU-limited games, frame-capped games, and workloads that do not approach thermal or power limits may see little or no measurable performance difference.

The primary improvement is that the cooling policy reacts earlier and more predictably to sustained GPU activity, which should reduce the chance of performance dropping later in a workload because the cooling system took too long to respond.

The intention is not to run the fans aggressively at all times. During normal desktop use, the system remains under firmware control and stays quiet. Manual cooling is only engaged when the GPU becomes active or temperatures begin to rise.

On my HP OMEN MAX 16, this has been tested during sustained AI inference workloads as well as normal desktop operation. Cooling behavior has been more predictable than the Windows OEM implementation for my use case, particularly during long-running GPU workloads.

One important compatibility change:

The kernel module now refuses to load on unvalidated system boards by default. My validated platform is:

  • HP OMEN MAX Gaming Laptop 16-ak0xxx

  • Board 8D87

  • RTX 5080 Laptop GPU

  • BIOS F.07

  • Fedora Linux 44

Users testing another OMEN board, including the previously reported 8D41 or 8C58 systems, must now explicitly acknowledge the unsupported-hardware risk:

sudo ./install.sh --force-unsupported

This option should not be used merely to bypass an installation error. HP WMI fan and power commands are firmware-specific, and a command that is safe on one board may behave differently on another.

CachyOS users should still build using the kernel’s Clang/LLVM toolchain:

sudo env LLVM=1 CC=clang LD=ld.lld ./install.sh

After installation, verify both the GPU unlock and fan controller:

cat /sys/kernel/omen_wmi_boost/gpu_state
cat /sys/kernel/omen_wmi_boost/fan_state

systemctl status omen-wmi-boost-verify.service
systemctl status omen-wmi-fan-control.service

Expected GPU state should include:

ctgp=1 ppab=1

The fan policy is configurable through:

/etc/omen-wmi-fan-control.conf

Before applying a modified configuration, validate it without changing the hardware:

sudo /usr/local/sbin/omen-wmi-fan-control --dry-run --once

The earlier unlock-only implementation has been preserved in the repository’s original branch for users who do not want the cooling controller or newer platform restrictions.

Users on boards other than 8D87 are welcome to test the updated version, but please include the following when reporting results:

sudo dmidecode -s system-product-name
sudo dmidecode -s baseboard-product-name
sudo dmidecode -s bios-version

uname -r
nvidia-smi -q -d POWER

cat /sys/kernel/omen_wmi_boost/gpu_state
cat /sys/kernel/omen_wmi_boost/fan_state

journalctl -u omen-wmi-boost-verify.service -b
journalctl -u omen-wmi-fan-control.service -b

Please remove serial numbers, UUIDs, hostnames, and other unique machine identifiers before posting logs.