How to Check Your AMD P-State Driver Mode on Linux

Your Ryzen laptop may be running a frequency driver you have never looked at. It may also be running the older one, in which case the AMD P-State news does not apply to you yet. Two short commands tell you which driver is active, and a third explains the mode.

CPU frequency scaling is where new Ryzen generations get their power behavior on Linux. Phoronix's headline, Linux 7.4 AMD P-State Driver Will Be Ready For Ryzen Zen 6 CPUs, shows the driver is a recurring part of AMD hardware enablement. That headline is the only detail this guide takes from the article, so it makes no claims about specific chips, kernel dates or performance. It focuses on what you can verify on your own machine today.

A note on testing: None of the commands below have been run on a test machine. Every output is labeled "expected" and is based on the kernel's amd-pstate documentation. Your output will differ by CPU, kernel and distribution.

Prerequisites checklist

Work through this list before you change anything.

1. A Ryzen CPU. This guide targets Zen 2 and newer, but support depends on your kernel and firmware. Confirm details in the documentation.
2. A reasonably recent kernel. Check yours with uname -r. Active and guided modes arrived in later kernels than the original passive mode, so confirm specifics in the documentation.
3. Firmware settings. The documentation says the driver relies on ACPI CPPC. If the driver does not load, look for a CPPC option in your BIOS or UEFI setup.
4. Bootloader access. Know whether you use GRUB or systemd-boot, and make sure you can reach the boot menu at startup.
5. A backup of your bootloader config. For GRUB, run sudo cp /etc/default/grub /etc/default/grub.bak. For systemd-boot, copy the relevant file in /boot/loader/entries/ (the path varies by distribution).

Step 1: Check which driver you are running

Start with the file that names the active scaling driver.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

Expected output is one of these:

| Expected output | Meaning | | --- | --- | | amd-pstate-epp | amd-pstate in active mode | | amd-pstate | amd-pstate in passive or guided mode | | acpi-cpufreq | The older generic ACPI driver, not amd-pstate |

The name alone cannot separate passive from guided. The next step does.

Step 2: Read the amd-pstate mode

cat /sys/devices/system/cpu/amd_pstate/status

Expected output is a single word: active, passive, guided or disable.

If this file does not exist, amd-pstate is not loaded. That usually means one of four things: See read about raspberry pi 5 alternatives after the $77.50 price hike for additional background.

• The kernel lacks support for your CPU.
• CPPC is off or missing in firmware.
• The parameter amd_pstate=disable is set.
• The system fell back to acpi-cpufreq.

Run cat /proc/cmdline to check for the parameter. Run sudo dmesg | grep -i pstate to look for kernel messages. Those messages vary by system, so read them rather than matching exact text.

Step 3: Cross-check with cpupower

cpupower frequency-info

Expected output includes a line such as driver: amd-pstate-epp, plus the available governors and frequency limits. If the command is missing, install it first. The package name differs by distribution: linux-tools on Debian and Ubuntu, kernel-tools on Fedora, cpupower on Arch.

Treat the three results as one check. The driver name, the status file and cpupower should agree. If they do not, trust the sysfs files and investigate.

Step 4: Pick a mode

The documentation describes three modes. Here is a plain comparison.

| Mode | Who decides frequency | Expected governors | Pick it when | | --- | --- | --- | --- | | active | The CPU firmware, guided by an energy performance preference hint from the kernel | performance, powersave | You want the driver's default-style behavior and minimal tuning | | passive | The kernel governor, requesting specific performance levels | Familiar ones such as schedutil or ondemand | You rely on classic governors or need predictable, kernel-controlled behavior | | guided | The hardware, within minimum and maximum limits the kernel sets | Kernel-governor style, per the documentation | You want kernel-set bounds with autonomous hardware selection |

The next point is an inference, not a documented recommendation. If your system works well and your battery life and temperatures are acceptable, leave the mode alone. Change it when you have a concrete reason, such as a governor you need or a misbehaving idle state you are trying to isolate. Change one thing at a time so you can tell what helped.

Step 5: Change the mode with a kernel parameter

The documented parameter is amd_pstate=, with values such as active, passive, guided or disable. Add it to your kernel command line.

GRUB

Edit /etc/default/grub and append the parameter inside the existing quotes:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_pstate=passive"

Then regenerate the config. Expected commands by distribution:

| Distribution | Expected command | | --- | --- | | Debian, Ubuntu | sudo update-grub | | Fedora | sudo grub2-mkconfig -o /boot/grub2/grub.cfg | | Arch, Manjaro | sudo grub-mkconfig -o /boot/grub/grub.cfg |

Fedora's file location can differ on EFI systems, so check your own setup before overwriting anything.

systemd-boot

Open your entry file in /boot/loader/entries/, find the line starting with options, and append amd_pstate=passive to it. Some distributions generate these files from /etc/kernel/cmdline or a similar source. If your tooling works that way, edit that source instead.

Verify after reboot

Reboot, then run:

cat /proc/cmdline
cat /sys/devices/system/cpu/amd_pstate/status
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

Also read: our guide to pgo + lto explained: do compiler tweaks really help?

Expected results: the command line contains your parameter, the status file shows the mode you chose, and the driver name matches the table in Step 1.

The documentation also describes writing a mode to the status file at runtime. Switching between certain modes may require passing through a disabled state, or may not be supported at all. Check the documentation before trying it, and use the boot parameter for changes you want to keep.

Step 6: Roll back if something goes wrong

Revert if you see stuttering, unexpected throttling, poor battery life or a governor that no longer behaves as you expect. Use these options in order:

1. Remove the amd_pstate= parameter from your GRUB line or systemd-boot entry, or restore the backup you made earlier (sudo cp /etc/default/grub.bak /etc/default/grub).
2. Regenerate the bootloader config with the command for your distribution from Step 5. systemd-boot users only need to save the entry file.
3. Reboot and repeat the checks from Steps 1 and 2.
4. If the system will not boot normally, hold Shift or press Esc at startup to open the boot menu. Then choose a previous kernel, or press e on the GRUB entry to remove the parameter for a single boot.

A one-time edit in the GRUB menu does not persist, so it is a safe way to test before you commit anything to disk.

After a kernel upgrade

Re-run the three checks. A new kernel can change the default mode or driver for your CPU, and your distribution's tooling may rewrite the command line. Confirm that /proc/cmdline still contains your parameter.

If you use a power profile service, it may adjust energy preferences in active mode. The documentation covers the underlying EPP interface.

What to expect next

As new kernels and Ryzen generations arrive, verify the driver name and mode after each upgrade rather than setting them once. Keep a note of your working parameter and your backup file. The kernel documentation is the authority on which modes your kernel and CPU support, so check it first when a release changes the behavior you see.