CPU Datestamp XXXX (e.g. above)

Motherboard BIOS Version

Are you using memory on your Motherboard's QVL list?

Kernel (`uname -r` output)

Is `CONFIG_RCU_NOCB_CPU=y` set?

Is `rcu-nocbs` set based on available threads? (e.g. `rcu-nocbs=0-15` for a Ryzen 7)

Have you explicitly disabled ASLR?

Does your system pass stress tests?

What stress tests have you used to validate hardware stability of CPU, mobo, and memory?

If your system is unstable (<=2), can you reproduce the problem consistently? If yes, how?

Have you automated synthetic load to keep core[s] busy?

What version of the ATXV12 standard does your power supply support?

ASRock Fatal1ty AB350 Gaming-ITX/ac

4.14.18-300.fc26.x86_64

Memtest for > 24hrs, stressapptest for > 24hrs, kill-ryzen script for > 24hrs

Despite my system being rock solid, if I lock my screens with gnome (which powers them off), system becomes unresponsive. Not sure if at all related to Ryzen hardware, but if I use i3lock (which keeps monitors on) instead of default gnome screen locker, then I have zero issues. That's the only "weirdness" that remains, but can have system running for months now without problems, and it's awesome.

4.60 (AGESA PinnaclePI-AM4 1.0.0.0)

Yes, via ryzen-stabilizator (similar to zenstates.py); have also processor.max_cstate=5

memtest86, memtest86+, mprime/prime95, occt, stressapptest

Also have pcie_aspm=off. With all these workarounds, system feels stable.

Can't check but post-RMA and new enough to not have segfaults

Gigabyte GA-AX370-Gaming 5

4.15.2-00005-g982d64f675d4

kill-ryzen.sh, Gentoo Linux ;-)

Maybe frozen once or twice since CONFIG_RCU_NOCB_CPU but can't be certain of the cause. Was almost daily before that. Also experienced motherboard "soft-brick" this week, probably unrelated. Managed to recover it.

just leave the system idling for a few hours to a few days

The memory is not found on the QVL list but it's ECC ram (Kingston KVR21E15D8K2/16I). I've had ASLR disabled but it didn't make any difference. That's the third Ryzen 1700x in that setup. The first two suffered from the segfault bug, not the current one, but all 3 of them showed those damned idle freezes. Perhaps it's just coincidence, but the freezes always happened when the screensaver was running (Xscreensaver) - never saw a freeze within the time period until the screensaver activated

Don't know, definitely produced after the segfaults under load problem.

Disabled via https://github.com/qrwteyrutiyoup/ryzen-stabilizator. Similar to zenstates.

stress, memtest86-efi, kill-ryzen, ryzen-mame-test

The only thing I've done is disable both C6 states. Before that, I never went more than two days before a complete freeze, and usually it would freeze after less than a day. I've now had 32 days of uptime without one.

I have two identical systems, functioning as servers. Overnight, after backups have finished (when most idle time occurs) they will randomly freeze.

This started happening after some months of functioning normally.

I am using ECC memory.

7A34vAA (2018-01-29, AGESA 1.1.0.1)

AMD Ryzen™ Threadripper™ 1950X

4.13.12-300.fc27.x86_64

kernel / gcc compile, memtest86

No more system freezes since enabled optimization for daily computing. All other BIOS configuration is standard besides activation of IOMMU and SVM. RAM runs at 2400 MHz per default. CPU is RMA'd

Memtest86+, ryzen-kill script (segfault test), kernel compilation, ffmpeg encoding

compilation workloads, AVX-based HPC workloads

Machine assembled 1st week of April 2017, reached idle stability with AGESA Code 1.0.0.6b + C6 disabled in BIOS. "echo 0 > /proc/sys/kernel/randomize_va_space" solved my crashes under heavy load.

stress --cpu 12 for a hour

Had random lock-ups every day before disabling C6. Now about a week without any problems.

Do not know, acquired on 2017-04-19

Ubuntu 16.04.3 LTS (amd64)

RAM: 2x Kingston 9965669-019.A00G (unbuffered, ECC) on DIMMs 1 A/B; Contact: linux-ryzen-poll 4T moritz-naumann D0T com

4.15.3.-300.fc27.x86_64

kill-ryzen.sh (failed on pre-RMA CPU, works now) and MemTest86

System has frozen every 2-3 days, needing to be turned on and off. Occasionally I get "soft lockup". The system used to get into a state where the mouse still moved, but nothing else worked -- that seemed to go away when I set 'rcu-nocbs'.

The kernel-command-line option "processor.max_cstate=5" does not seem to do anything -- not according to zenstates.py, at least.

I arranged for "zenstates.py --c6-disable" to run in rc.local two days ago. So far, no freezing. I also received the update from kernel v4.14 to v4.15 in the last few days, though I have no reason to believe that will make a difference.

If my machine does not freeze in the next couple of weeks, I will try re-enabling C6.

Everything ok after recompiling the kernel with CONFIG_RCU_NOCB_CPU=y and set rcu-nocbs=0-11 (for my ryzen 5). Before that, system stability was 1 (hangs every day)

? Components bought Aug 2017, but the manufacturing week, I did not record.

4.15.3-antix.1-amd64-smp

Run CPU jobs 700-1100% CPU in top (like squashfs, handbrake), MEMTEST 3 full cycles, long hours with workloads from near zero to loaded.

Since I added rcu_nocbs=0-11, no problems , uptime 9 days 1 hr. (updated 2.28.18)
Without that addition to grub, I would have 2 crashes per day, so far, I consider this one solved. RAM is 16G G. Skill FlareX DDR4 3200MHz with DOCP

Don't know, but it's RMA because of segfaults

sysbench, memtest86, Compiling with gcc (Gentoo)

without CONFIG_RCU_NOCB_CPU=y and bootparameter rcu-nocbs=0-15 it reproduces the Bug after some houres idle, CPU on demand gouvernor is using

4.15.5-1.el7.elrepo.x86_64

It hung with the kernel 4.15.4 and bios 3803.
With the kernel 4.14 and the previous bios, I was able to get 21 days without crash. Then stopped testing. The computer was left idle for 21 days. No load.
Now with kernel 4.15.5 and bios 3803, have deactivated C6 and deactivated EPU. Also increased cpu voltage to 1.85V

System stable since power and frequency were adjusted in the BIOS (see http://www.silence.host/node/1)

ASRock AB350 Gaming-ITX/ac

Using bios 4.50, sent to me from ASRock. Will test now with rcu-nocbs=0-7. Kernel 4.16-rc3 Manjaro's version works, Ubuntu 18.04's causes weird graphics.

ASRock AB350 Gaming-ITX/ac

Using bios 4.50, sent to me from ASRock. Will test now with rcu-nocbs=0-7. Kernel 4.16-rc3 Manjaro's version works, Ubuntu 18.04's causes weird graphics.

https://github.com/suaefar/ryzen-test
https://www.memtest86.com/

Yes. Let it idle for a random amount of time, wait for "CPU#X stuck" messages...

The PSU was produced in 2017 and is listed on the manufacturer's website as "Compliant to Intel C6/C7".

I don't know (only answer if you really have no way of finding this out)

no need stress test to freeze

This bug appears when I upgrade Ubuntu from 17.10 to 18.04 (I have a nvidia graphic card)

I don't know (only answer if you really have no way of finding this out)

dont know. bought it in mid april 2018

Gigabyte GA-AB350-Gaming 3 (rev. 1.x)

BIOS C6 package disabled (Typical idle voltage)

rebuilding gentoo from scratch

enable C6 package in BIOS

initially chased the freezes down by using zentstates.py and disabling C6. the freezes which occured within an hour if system was almost idle didnt show up after diabling C6 via script. after investigating the BIOS and finding out that I can turn off C6 package and leave C6 for the cpu turned on (verified by zenstates.py output) I changed the BIOS switch. No occurence of random freezes since then but I am NOT running 24/7.

4.18.20-041820-generic