ASUS ProStudio W7604 — Linux CPU Throttling Investigation

System

The Problem

The system was experiencing severe CPU frequency throttling under sustained multi-core load, specifically during long compilation jobs. The CPU would briefly run at higher frequencies for 10–15 seconds, then drop and hold at a fraction of its rated performance for the entire remainder of the workload.

This made compilation jobs significantly slower than expected for a high-end mobile workstation CPU.

Observed Symptoms

• Under stress-ng --cpu 0, CPU frequencies would burst to ~3.8 GHz for roughly 10–15 seconds, then permanently settle to:
  • P-cores: ~2.8 GHz
  • E-cores: ~2.3 GHz
• This plateau persisted for the entire duration of the load regardless of thermal headroom — temperatures were only ~74–80°C with fans barely active
• CPU package power draw would start at ~130W during the burst phase, then drop and hold at ~55W once throttled — the classic PL1 power limit clamp
• Fans were running at only ~3,800 RPM under full CPU load, indicating the firmware was not responding to the thermal demand
• The ACPI platform_profile and throttle_thermal_policy sysfs interfaces were not present — standard ASUS Linux tooling had no effect on the system
• scaling_available_frequencies (under acpi-cpufreq) reported a maximum of 2.401 GHz — the firmware was presenting a throttled P-state table to the OS

What We Were Fixing

1. Raise and maintain the MMIO RAPL power limits so the CPU can sustain higher than 55W under load — the direct cause of the frequency plateau
2. Switch the EC to its performance thermal profile at every boot, so fans respond correctly and the EC stops repeatedly resetting power limits to conservative values
3. Ensure the correct CPU frequency driver is loaded so the OS presents the correct hardware frequency ceiling to the scheduler rather than the firmware's throttled P-state table
4. Make all of the above persistent across reboots via systemd services and configuration files, since the EC resets all of this on every power cycle

CPU Core Topology — Intel Core i9-13980HX (Raptor Lake-HX)

CORE LAYOUT

Total cores:    24
Total threads:  32
P-cores:         8 x Intel Raptor Cove architecture (HT = 2 threads each = 16 threads)
E-cores:        16 x Intel Gracemont architecture (1 thread each = 16 threads)

FREQUENCY SPECIFICATIONS (Intel spec)

P-core base frequency:        2.2 GHz
P-core max turbo (single):    5.6 GHz
P-core max turbo (all-core):  ~3.5-4.5 GHz (workload dependent)
E-core max turbo:             4.0 GHz
E-core base frequency:        1.6 GHz

Note: The 5.6 GHz figure is the single-core Intel Turbo Boost Max 3.0 peak for the best-performing P-core. All-core sustained turbo under full load is significantly lower and depends entirely on power limits and thermal headroom.

CURRENT OBSERVED FREQUENCIES UNDER LOAD (this system)

Burst phase (~10-15s):         ~3.2-3.8 GHz P-cores, limited by PL2=130W
Sustained phase (after burst): previously ~2.8 GHz P / ~2.3 GHz E at 55W
                               now ~3.2-3.8 GHz P / ~2.4 GHz E at 100W
CPU cores in /proc/cpuinfo:   cpu0-cpu15  = P-cores (logical)
                               cpu16-cpu31 = E-cores

LINUX DRIVER NOTE

With intel_pstate=active, scaling_max_freq correctly reports 5.4 GHz for P-cores. With intel_pstate=disable (acpi-cpufreq), the ACPI _PSS table incorrectly reported 2.401 GHz as the ceiling for all cores — this was one of the early misdiagnoses in this session. The 4.0 GHz E-core ceiling previously caused confusion because intel_pstate in some modes reads it as the global hardware turbo limit, incorrectly capping P-cores at 4.0 GHz as well.

System Configuration — What Is Working

Kernel Boot Parameters

File: /boot/loader/entries/linux.conf (options line)

• acpi_enforce_resources=lax — Allows asus-isa-000a hwmon driver to load. Exposes /sys/class/hwmon/hwmonX/pwm1_enable and pwm2_enable. Required for any fan control from the OS side.
• intel_pstate=active — Uses Intel P-state driver directly. Bypasses ACPI _PSS table which incorrectly caps at 2.4 GHz. Correctly exposes 5.4 GHz scaling_max_freq. Note: intel_pstate=disable was tried and reverted — it caused acpi-cpufreq to read the _PSS table and cap frequencies at 2.401 GHz, making performance worse.

throttled (/etc/throttled.conf)

• Continuously re-applies CPU package power limits every 5 seconds
• Targets BOTH MSR and MMIO (intel-rapl-mmio) RAPL domains
• Critical: the EC resets the MMIO RAPL domain to ~55W every few seconds; without throttled the CPU sustains only ~55W / ~2.8 GHz
• With throttled at PL1=100W the CPU sustains ~100W / ~3.2-3.8 GHz

Key settings in [AC] section:

Enabled: True
Update_Rate_s: 5
PL1_Tdp_W: 100
PL1_Duration_s: 128
PL2_Tdp_W: 130
PL2_Duration_s: 0.002
Trip_Temp_C: 95

Note on PL2: Intel spec for i9-13980HX is 55W base TDP / 157W max turbo. 130W is a conservative, thermally safe choice for PL2. ASUS ROG Turbo mode sets PL1=170W/PL2=175W on the same CPU — so 130W has plenty of headroom.

systemctl enable --now throttled

ASUS Performance Mode Service

File:    /usr/local/bin/asus-performance-mode.sh
Service: /etc/systemd/system/asus-performance-mode.service
systemctl enable asus-performance-mode.service

What it does at every boot:

1. modprobe acpi_call / modprobe msr
2. echo '\_SB.ATKD.FANL 0x02' > /proc/acpi/call — Calls ACPI method to set EC thermal profile to performance. Causes EC fans to spin up more aggressively. MUST be called at every boot — EC resets to conservative profile on reboot.
3. Re-applies RAPL limits (belt-and-suspenders backup to throttled): PL1=100W and PL2=130W on both intel-rapl:0 and intel-rapl-mmio:0

Fan Control

ASUS hwmon device: /sys/class/hwmon/hwmon12 (may renumber on reboot; use: grep -rl "^asus$" /sys/class/hwmon/*/name to find it)

Mode values: 0 = full speed (EC hands off), 2 = EC automatic control

# Force full speed:
echo 0 > /sys/class/hwmon/hwmon12/pwm1_enable
echo 0 > /sys/class/hwmon/hwmon12/pwm2_enable

# Return to EC auto:
echo 2 > /sys/class/hwmon/hwmon12/pwm1_enable
echo 2 > /sys/class/hwmon/hwmon12/pwm2_enable

Note: FANL 0x02 performance profile causes the EC automatic curve to be more aggressive than the default conservative profile.

cpupower (/etc/default/cpupower-service.conf)

GOVERNOR='performance'
MIN_FREQ="800MHz"
MAX_FREQ="5600MHz"
systemctl enable cpupower

Current Performance Results

Sustained CPU package power:  ~100W (up from 55W)
Sustained P-core frequency:   ~3.2-3.8 GHz all-core under load
Max CPU temperature:          ~93C under heavy load
Fans:                         EC automatic, performance profile

Dead Ends — Things Tried That Didn't Work

Driver / Kernel Parameter Attempts

• intel_pstate=disable / acpi-cpufreq — reads ACPI _PSS table which caps at 2.401 GHz; made performance worse; reverted to intel_pstate=active
• intel_pstate=passive — same _PSS table ceiling problem; did not fix the frequency cap
• cpupower frequency-set -u 5400000 — ignored when hardware limit is reported as 4 GHz; no effect against firmware-level caps
• scaling_max_freq overrides per-core — writing 5600000 to individual cores did not change sustained frequency under load

RAPL / Power Limit Attempts

• Writing MSR RAPL domain only (intel-rapl:0) — the intel-rapl-mmio domain was independently capped at ~55W; MSR writes had no effect because MMIO domain was the binding limit

BD_PROCHOT MSR Clearing

• wrmsr -a 0x1FC 0xe40050 (one-shot) — EC reasserts bit 0 within milliseconds; no lasting effect
• Continuous wrmsr loop — EC writes the MSR back faster than any OS userspace loop; no measurable effect
• CWAP ACPI method (\_SB.ATKD.CWAP with values 0x00-0x05) — just OR-masks an in-memory flag; no connection to BD_PROCHOT; all calls returned success but had zero effect
• throttled with Disable_BDPROCHOT: True — EC reasserts within milliseconds; BD_PROCHOT is a symptom, not the root cause

Fan Control Attempts

• asus-nb-wmi / throttle_thermal_policy sysfs — not exposed on W7604
• platform_profile / asus-armoury — "No matching power limits found for this system"; W7604 not supported
• asusctl / asusd — could not control fan curves or thermal profiles on this model
• nbfc-linux (UX550VE profile) — EC dumps all zeroes; wrong EC address entirely
• ec-probe (all access modes) — all zeroes; EC is not at standard I/O ports 0x62/0x66
• ec-probe.exe on Windows 11 — also all zeroes; confirmed non-standard EC address
• RWEverything on Windows 11 — driver blocked by Windows even with Memory Integrity and Vulnerable Driver Blocklist disabled
• MsiEcRamEditor on Windows 11 — all zeroes; confirms EC is ACPI-method-only, not I/O accessible
• fancontrol / pwmconfig — no pwm1/pwm2 value files exist on the ASUS hwmon device; granular curve configuration not possible

Key Technical Findings

1. ROOT CAUSE OF FREQUENCY CAP — The intel-rapl-mmio (MCHBAR/MMIO) RAPL domain has an independent ~55W PL1 cap that the EC resets every few seconds. This is the binding power limit. throttled writing both MSR and MMIO domains every 5 seconds is the correct fix because the EC reset cadence is multi-second (winnable by a daemon), unlike BD_PROCHOT which is reset in microseconds.
2. EC IS ACPI-METHOD-ONLY — The W7604's EC is not accessible at standard I/O ports. All direct EC access tools (Linux and Windows) return all zeroes. The only way to communicate with the EC is via ACPI method calls (RRAM, WRAM, FANL in the DSDT). This is exactly what Armoury Crate does on Windows.
3. FAN PWM CONTROL IS BINARY — The hwmon device only exposes pwm1_enable/pwm2_enable mode files. No pwm value files exist. The only choices are EC automatic (2) or full speed (0). Granular fan curve control from Linux is not available on this hardware through any confirmed method.
4. FANL 0x02 IS THE CORRECT PERFORMANCE PROFILE CALL — Calling \_SB.ATKD.FANL 0x02 via acpi_call sets the EC to its performance thermal profile. Must be applied at every boot — the EC resets to conservative profile on every reboot.
5. BD_PROCHOT IS A SYMPTOM — BD_PROCHOT (MSR 0x1FC bit 0) being asserted by the EC is a consequence of the conservative power profile, not an independent cause of the frequency cap. The actual binding constraint is the MMIO RAPL power limit.
6. i9-13980HX POWER LIMIT REFERENCE — Intel spec: PL1 = 55W, PL2 = 157W. Current config: PL1=100W, PL2=130W — conservative and thermally safe. ASUS ROG Turbo mode uses PL1=170W/PL2=175W on the same CPU.

Open Items / Still Being Investigated

• Granular fan curve control via asus-fan-control + afc-scout (in progress — may work now that acpi_call is loaded)
• Fan aggressiveness: EC auto with FANL 0x02 is acceptable but more aggressive curve control would be preferable

Misc Monitoring Commands

Freqs, temps and fan speeds

#!/usr/bin/env fish
echo "=== GOVERNOR ==="
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "=== FREQUENCIES ==="
cat /proc/cpuinfo | grep "MHz"
echo "=== TEMPS ==="
sensors 2>/dev/null | grep -E Core | grep -oP '\+\K[0-9]+\.[0-9]+(?=°C\s+\()' | sort -n | awk 'NR==1{min=$0} END{print "Min: " min "°C  Max: " $0 "°C"}'
echo "=== FANS ==="
sensors 2>/dev/null | grep -i fan

watch -n .2 ~/sysmon.fish

CPU package power draw

while true
    set e1 (cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/energy_uj)
    sleep 1
    set e2 (cat /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/energy_uj)
    echo (math "($e2 - $e1) / 1000000")" W"
end

Force fans to full speed

echo 0 | tee /sys/class/hwmon/hwmon12/pwm1_enable
echo 0 | tee /sys/class/hwmon/hwmon12/pwm2_enable
# set back to 2 to return to automatic