Ryzen

Ryzen
is a brand of microprocessors  manufactured by Advanced Micro Devices (AMD). This article covers system configuration and troubleshooting information for different generations of the CPU.
This article or section needs expansion.
Reason:
Add something about
amd_pstate
or at least link to
CPU frequency scaling#Scaling drivers
. (Discuss in
Talk:Ryzen
)
Related articles
Improving performance
Improving performance/Boot process
Kernel
Microcode
Enable microcode support
Install
the
amd-ucode
package to enable microcode updates and enable it with the help of the
Microcode
page. These updates provide bug fixes that can be critical to the stability of your system. It is
highly recommended
to use it despite it being proprietary.
Tweaking Ryzen
Voltage, power and temperature monitoring
lm_sensors
should be able to monitor temperatures out of the box. However, for more detailed information such as power consumption and voltage,
zenpower3-dkms
AUR
is needed. For GUI based monitoring tools, use
zenmonitor
AUR
or
zenmonitor3-git
AUR
for Zen 3 CPUs.
Power management, undervolting and overclocking
RyzenAdj
— RyzenAdj is a command-line tool that can adjust power management settings for Ryzen mobile processors.
https://github.com/FlyGoat/RyzenAdj
||
ryzenadj-git
AUR
amdctl
— amdctl is a command-line tool for under/over clocking/volting AMD CPUs, currently supporting AMD CPU families 10h, 11h, 12h, 15h, 16h, 17h and 19h.
https://github.com/kevinlekiller/amdctl/
||
amdctl
AUR
ZenStates-Linux
— ZenStates is a command-line tool to adjust the clock speed and voltage. A detailed setup example is given in
Level1Techs
forum.
https://github.com/r4m0n/ZenStates-Linux
||
zenstates-git
AUR
ryzen_smu
— Ryzen SMU is a Linux kernel driver that exposes access to the SMU (System Management Unit) for certain AMD Ryzen Processors. Can for example be used for undervolting the 5800x3D (see
this script
as an example).
https://github.com/amkillam/ryzen_smu
||
ryzen_smu-dkms-git
AUR
AMD 3D V-Cache scheduling (multi-CCD CPUs)
On CPUs with asymmetric CCDs (e.g. 7950X3D, 9950X3D), one CCD has 3D V-Cache (larger L3,
better for gaming) and one has higher clock speeds. The
amd_x3d_vcache
driver
(kernel 6.13+) exposes a scheduling bias via sysfs.
First, set
CPPC Dynamic Preferred Cores
to
Driver
in the UEFI (on MSI boards:
OC -> Advanced CPU Configuration -> AMD CBS -> CPPC Dynamic Preferred Cores
).
Without this, the sysfs override has no effect.
The recommended setup is to leave the system in
frequency
mode (default), so the
OS and background tasks prefer the faster non-X3D CCD, and pin games explicitly to the
X3D cores:
# echo frequency > /sys/bus/platform/drivers/amd_x3d_vcache/AMDI0101:00/amd_x3d_mode
To identify which cores are the X3D cores, read the prefcore rankings, in
frequency
mode the X3D cores will have the
lowest
rankings:
$ grep -r
/sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_prefcore_ranking
On the 9950X3D these are cpu0–7 and cpu16–23. For
native Linux games
pin them via
the Steam launch option:
taskset -c 0-7,16-23 %command%
For
Proton/Wine games
,
taskset
does not propagate into the Steam Proton
container (pressure-vessel). Use
WINE_CPU_TOPOLOGY
instead:
WINE_CPU_TOPOLOGY=16:0,1,2,3,4,5,6,7,16,17,18,19,20,21,22,23 %command%
The format is
<thread_count>:<comma-separated CPU list>
.
Compiling a kernel
See
Gentoo:Ryzen#Kernel
on enabling Ryzen support. The
officially supported kernels
have the required configuration by default.
Troubleshooting
Random reboots
See
Gentoo:Ryzen#Random_reboots_with_mce_events
if you are experiencing random reboots.
With Ryzen 5000 series, particularly the higher-end models of 5950X and 5900X there seem to be some slight instability issues under Linux, related possibly to the 5.11+ kernel, as shown by
this kernel bug
. After investigating and reading reports on the Internet, It seems that out of the box, Windows seems to run the CPUs at higher voltage and lower peak frequencies, compared to the stock linux kernel, which depending on your draw from the silicon lottery could cause a host of random application crashes or hardware errors that lead to reboots. You will recognise those by dmesg logs that look like:
kernel: mce: [Hardware Error]: Machine check events logged
kernel: mce: [Hardware Error]: CPU 22: Machine Check: 0 Bank 1: bc800800060c0859
kernel: mce: [Hardware Error]: TSC 0 ADDR 7ea8f5b00 MISC d012000000000000 IPID 100b000000000 
kernel: mce: [Hardware Error]: PROCESSOR 2:a20f10 TIME 1636645367 SOCKET 0 APIC d microcode a201016
The CPU ID and the Processor number may vary. To solve this problem you need to supply higher voltage to your CPU so that it is stable when running at peak frequencies. The easiest way to achieve this is to use the AMD curve optimiser which is accessible via your motherboard's UEFI. Access it and put a positive offset of 4 points, which will increase the voltage your CPU is getting at higher loads. It will limit overclocking potential due to higher heat dissipation requirements, but it will run stable. For more details check
this forum post
. When I did this for my 5950X, my processor stabilised and the frequency and voltage ranges were more similar to those observed under windows.
System halts
Within similar context of
#Random reboots
, systems might halt under heavy or specific low loads, even after applying the fixes. Reset button or forced shutdowns don't work, peripherals powers off, video output might stop, and unplugging is the only way out of this state.
Reducing frequencies to within non-overclocked standards and increasing voltages of CPU or RAM helps, but might not fix the issue. A potential fix is to update the UEFI (also misnamed "BIOS updates"), and then apply the PBO+4 curve for more stability on higher frequencies. Per silicon lottery, some CPUs might need +6 or higher offsets.
Screen-tearing (APU)
If you are using
Xorg
and are experiencing screen-tearing, see
AMDGPU#Tear free rendering
.
Soft lock freezing
This bug is well known and is being discussed on
bugzilla
and
launchpad
. While the solution is not the same in all cases,
this
one helped some users. Add the output of this command
echo rcu_nocbs=0-$(($(nproc)-1))
as a kernel parameter where the command
nproc
just prints your CPU's threads. For this option to be applied, you need a compiled kernel with option
CONFIG_RCU_NOCB_CPU
(like
linux
).
A different cause for the freezes is the power saving management indicated by c-states. The maximum power saving state c6 can cause problems. Adding the kernel parameter
processor.max_cstate=5
helped in some cases but other users reported that the option is not applied and the c6 state is still entered. For them,
disabling C6 states
through a helper script relying on
zenstates-git
AUR
helped. Before using it,
modprobe msr
needs to be run in order to activate that kernel module.
Some laptops with Ryzen CPUs such as the HP Envy x360 15-bq100na may experience CPU soft locks which result in a frozen system. These can be avoided with the kernel parameter
idle=nomwait
added.
In some cases, kernel parameter
pci=nomsi
fixes the issue.
In some other cases, the issue is simply bad hardware, and warranty claiming the CPU for a new one may just solve your issues.
Freeze on shutdown, reboot and suspend
Note
This problem may be resolved with newer AGESA firmware, available through a UEFI update (often referred to as a "BIOS update").
This issue is strongly linked to the C6 CPU idle state, which can cause instability on Linux, particularly when used with power supplies or motherboards that do not handle ultra-low current draw well.
To mitigate this, enter the UEFI setup:
Locate the setting called
Power Supply Idle Control
(or similar).
Change it from
Low Current Idle
to
Typical Current Idle
.
This disables deeper idle states (such as C6), allowing only C1 and C2. While this slightly increases power consumption, it significantly improves system stability.
Note
This UEFI change can also resolve the
soft lock freezing
issue described above, as both are commonly caused by unsupported or unstable deep C-states.
If your motherboard does not offer this setting, or if issues persist, alternative workarounds include:
Fully disabling C-states in UEFI (if available, though not always recommended).
Adding the following kernel parameter to limit CPU idle state:
processor.max_cstate=1
Disabling deep C-states may raise idle power consumption by approximately 5–10 W, but typically resolves issues with suspend, reboot, and shutdown on affected systems.
See also
Gentoo:Ryzen