Ryzen

Ryzen is Article description::a multithreaded, high performance processor manufactured by AMD. The first generation based on the Zen microarchitecture (µarch) was released in Q1, 2017 as Ryzen 1000 series. A refresh called Zen+ was released in Q2, 2018, as the Ryzen 2000 series. The second generation is the Ryzen 3000/4000 series, based on the Zen 2 microarchitecture, and was released in Q3, 2019.

Firmware
To install the Zen microcode, emerge :

The firmware blobs will need to be added to the kernel in order to be loaded.

Kernel
Enable support for Ryzen hardware in kernel 4.11.0:

While configuring the kernel, it is a good idea to build in any appropriate AMD microcode updates needed by the CPU.

Those using with the   USE flag will have additional Processor family options made available:

This enables  to be set for the kernel's  process.

GCC 6.3 and newer
GCC 6.3+ has support for the  compiler optimization. For optimal performance, this can be enabled in.

GCC 5.4
While GCC 5.4 does not support Zen core specific optimization,  has been shown to be functional and stable. However, since Zen dropped the instruction set extensions FMA4, TBM, XOP and LWP, they should be disabled accordingly:

Optional, but may produce better code: Add new instruction set extensions introduced with Zen individually (ADCX, RDSEED, MWAITX, SHA, CLZERO, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT), using  (Bulldozer Version 4 i.e. Excavator) as the starting point:

Drivers for lm-sensors
The HWMON (lm-sensors) driver for Asus motherboards of this class are currently not part of the kernel. Consider using the asus-wmi-sensors driver available under https://github.com/electrified/asus-wmi-sensors. Please also check if the motherboard is supported or not.

An ebuild is available using an overlay. Add it with either:

or:

Segmentation faults during compilation
If segmentation faults (segfaults, short SEGVs) are encountered frequently on Zen it might be anything from a software bug to a hardware bug. Since the CPU is under heavy load during a compilation process, this is most commonly the very time to discover such recurring SEGVs. With certain adjustments it may be possible to mitigate these segfaults—there have been reports of success and failure.

When encountering frequent SEGVs, please first ensure the most recently compiled binutils is selected via

If an early CPU batch is affected (2017), it should be/have been replaced through RMA (Return Merchandise Authorization) which AMD provides on its website. The recommendation to disable all overclocking and set proper timings for RAM is only for systems that were overclocked—at the designated speed CPU and RAM will not produce recurring SEGVs!

Faulty Hardware
As of 2017-08-08 AMD confirmed a problem residing inside the Ryzen processor itself. This problem should only affect the very few early Ryzen batches that were produced (available and sold mid-2017). AMD confirmed the issue and RMA was possible within the warranty period.


 * Consider downgrading or upgrading the BIOS/UEFI to the most stable.
 * Some motherboards' BIOS/UEFI setups have an option to disable OPCache. This has been observed to limit or stop segfaults albeit with a 5-7% performance cost.
 * Some users have reported that disabling ASLR resolves the segfault issues. This can be done at runtime by issuing  and to make it permanent:

Related forum topics: 1 and 2. And a Phoronix forum topic.

Overclocking or wrong settings
When experiencing segfaults on an otherwise healthy system, the following could help to solve the problem:
 * Ensure using the newest binutils; an older instance of binutils could be built against older opcode facilitating crashes due to poor linkage.
 * Ensure RAM voltage and timing are correct for the RAM; BIOS/UEFI implementations are conservative while performing autosetting.
 * Consider downgrading the BIOS/UEFI to the most stable version. ASUS and ASRock have been known to push very beta BIOS/UEFI versions that have shown to be quite unstable.

Random reboots with mce events
Likely due to errata 1109 a Ryzen system may encounter random, spontaneous reboots with MCE hardware errors being logged on startup. An example MCE event looks like this: Oct 31 11:46:23 fire kernel: [   0.677235] [Hardware Error]: System Fatal error. Oct 31 11:46:23 fire kernel: [   0.677439] [Hardware Error]: CPU:10 (17:1:1) MC5_STATUS[-|UE|MiscV|PCC|AddrV|-|-|SyndV|TCC]: 0xbea0000000000108 Oct 31 11:46:23 fire kernel: [   0.677798] [Hardware Error]: Error Addr: 0x0001ffff810796c0 Oct 31 11:46:23 fire kernel: [   0.678003] [Hardware Error]: IPID: 0x000500b000000000, Syndrome: 0x000000004d000000 Oct 31 11:46:23 fire kernel: [   0.678356] [Hardware Error]: Execution Unit Extended Error Code: 0 Oct 31 11:46:23 fire kernel: [   0.678562] [Hardware Error]: Execution Unit Error: Watchdog timeout error. Oct 31 11:46:23 fire kernel: [   0.678562] [Hardware Error]: cache level: RESV, tx: GEN, mem-tx: GEN

Suggested workarounds include:
 * Adding the kernel boot parameter . Note that any solution that prevents the kernel from executing the   instruction will not prevent the issue from occurring 100% of the time, as other code could execute the instruction.
 * Modifying the "Power Supply Idle Control" setting in the BIOS.
 * Consider disabling C-States. This can be done the BIOS/UEFI or with the boot parameter.

See also this kernel bugzilla entry, this AMD forum discussion, and many other discussions.

External resources

 * http://www.phoronix.com/scan.php?page=article&item=amd-ryzen-znver1&num=1 - Phoronix compiler optimization benchmarks for Ryzen 7.