I tried downgrading my arch install to various kernels with no luck. What ended up working is downgrading systemd to version 237. I used the systemd-git aur package and modified the pkgbuild to point to the older git tag. Now arch is booting.
Hopefully this helps as a stop-gap until it’s fixed.
Interesting. I will lol so hard if systemd div by zero because the CPU is too fast is the root cause
Very interested in following this thread. Got a Crosshair Vi Hero on launch for the very reason of upgrading later down the line.
Doesn’t say anything in the ASUS website about support for 3000 series…yet
I’ll be getting a 3900X tomorrow to run on an older x370 motherboard, will report any findings (I run arch so I assume I’ll see the same issues)
Will try the systemd downgrade as outlined above
Did you try systemd git package without forcing the versions ? As it could possibly be fixed in git already ?
Im still wondering why these x570 Boards are all PWM monsters that can deliver 300+W and all the tests the new chips used less power 
Look forward to how it turns out. I saw a few board makers says they will not support the new chips on old MB’s
I have a asus x370 board which seems to have to power delivery needed.
So something like Alpine or Void Linux would work, right?
What the heck?!? Systemd IGNORES kernel parameters? It’s like the kernel ignoring C-state parameters from the BIOS…
There should definitely be a configuration toggle within systemd so that this doesn’t happen where it’s forced on, despite what kernel arguments are used. It makes so much more sense to just have a damn toggle.
Can you try playing with the high_quality_required Boolean, @wendell? Apparently this was a change made in 2018 to systemd as reported by Phoronix:
https://www.phoronix.com/scan.php?page=news_item&px=Systemd-RdRand-Direct
And the forum thread is extremely confused as to what value the Boolean should be…
I think it’s just systemd.high_quality_required=false as a kernel parameter… That’s my speculation anyways.
That’s crazy though that the rdrand on Ryzen 3000 has negative integers, which is a BIG no no.
I found some explanations of this bug:
https://linuxreviews.org/AMD_Ryzen_3000_series_CPUs_can't_do_Random_on_boot_causing_Boot_Failure_on_newer_Linux_distributions
https://www.golem.de/news/linux-abstuerze-fehlerhafter-zufallsbefehl-auf-neuen-und-alten-amd-cpus-1907-142433.html (German)
Alpine Linux is superb on a server or as a container .
For a desktop without systemd a good alternative is Artix Linux (Arch with openrc)
Jokes on you! All my distros are ubuntu 18.04 / 16.04 based! Also I don’t own Ryzen 3000 (…yet…)
AMD just confirmed the negative integer issue will be solved in a BIOS/AGESA update.
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-Linux-Zen2-Fix
I’ve tested the RDRAND on Windows 10, and heres my result:
On a laptop with 2500u:
On a desktop with 3700x:
So I guess it’s probably neither a problem with systemd nor the linux kernel, but a problem with the processor itself (or the bios / firmware).
Wow.
I was going to ask if 3000 was good yet. Been looking at a 3750u for a bit.
Guess not lel.
Check the ryzen 3000 mega thread. Wendell said that their were issues that were caused by the bios.
and it is resolved now, updated bioses have already started dropping.
Any release-notes that can be shedding light on the issue itself?
Rdrand would sometimes return carry flag as if the random number was random but it was not actually random. Also affected destiny 2 on windows
3750H is not Zen 2, it’s Zen+ still. That’s immune from this bug.
