Project

General

Profile

Actions

Regression #17025

closed

AMD CPPC defaults to maximum-performance policy after 26.07 upgrade, increasing idle temperatures

Added by Mike A 10 days ago. Updated 8 days ago.

Status:
Needs Patch
Priority:
Normal
Assignee:
-
Category:
FreeBSD
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.9.0
Affected Architecture:
amd64

Description

Summary

After upgrading a custom amd64 pfSense Plus system with an AMD Ryzen 7 to 26.07, idle CPU temperature increased from approximately 40-41 C to 60-65 C while the system remained approximately 99% idle.

Since pfSense Plus 26.07 uses a FreeBSD 16 base which activates the new hwpstate_amd CPPC support on this system. With no user CPPC tunables configured, every logical CPU showed desired_performance equal to its own maximum_performance and EPP set to 0.

Representative values from CPU 0:

dev.hwpstate_amd.0.minimum_performance: 12
dev.hwpstate_amd.0.maximum_performance: 196
dev.hwpstate_amd.0.desired_performance: 196
dev.hwpstate_amd.0.epp: 0

FreeBSD documents maximum performance as the intentional initial policy to avoid performance regressions while powerd integration is still incomplete:

https://www.freebsd.org/status/report-2026-01-2026-03/cppc/

Steps to reproduce

  1. Boot pfSense Plus 26.07 on an AMD CPPC-capable Ryzen system without user CPPC tunables.
  2. Allow the system to reach a stable idle state.
  3. Confirm the CPU is approximately 99% idle.
  4. Inspect the policy:
sysctl dev.hwpstate_amd.0.minimum_performance \
       dev.hwpstate_amd.0.maximum_performance \
       dev.hwpstate_amd.0.desired_performance \
       dev.hwpstate_amd.0.epp

Actual result

All 16 logical CPUs requested their maximum performance level with EPP 0. Idle temperature was 60 C during a controlled baseline and periodically reached 65-68 C, compared with approximately 40-41 C before the 26.07 upgrade.

Runtime workaround and validation

With machdep.hwpstate_pkg_ctrl=1, the following runtime change propagated to all logical CPUs:

sysctl dev.hwpstate_amd.0.desired_performance=0 \
       dev.hwpstate_amd.0.epp=128

This selects autonomous performance control with a balanced EPP while leaving the minimum and maximum capabilities unchanged.

Results:

  • Idle temperature fell from 60 C to 41-42.0 C while CPU idle remained 97-99%.
  • A controlled single-core load still boosted to approximately 5.2-5.27 GHz.
  • A 3 Gb/s WAN sustained test used approximately 7% aggregate CPU, raised temperature from 41 C to only 43 C, and temperature immediately returned to 41 C.
  • PPPoE, Suricata, Unbound, ntopng, and gateway monitoring remained healthy.

The working policy is currently applied through these native pfSense System Tunables:

dev.hwpstate_amd.0.desired_performance=0
dev.hwpstate_amd.0.epp=128

Expected result / question

An upgrade should not substantially increase idle thermals on an otherwise idle system. I understand that the driver and initial policy are inherited from upstream FreeBSD. Could the pfSense kernel team review whether the upstream maximum-performance policy is appropriate as the pfSense default on CPPC-capable AMD systems, or whether pfSense should apply or expose a supported autonomous/EPP policy?

Actions #1

Updated by User Me 8 days ago

Looks like there is an upstream bug about the lack of powerd support: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295793

Actions #2

Updated by Marcos M 8 days ago

  • Status changed from New to Needs Patch
Actions #3

Updated by Marcos M 8 days ago

  • Project changed from pfSense Plus to pfSense
  • Category changed from FreeBSD to FreeBSD
  • Affected Plus Version deleted (26.07)
  • Affected Version set to 2.9.0
Actions

Also available in: Atom