New Asrock X470 Taichi UEFI 1.50

The issue has been reported to Red Hat.

https://bugzilla.redhat.com/show_bug.cgi?id=1608242

Many thanks for this!

I hope it's not against any rules or anything to talk about other vendors here, because I don't have an ASRock board but I'm having the same problem and this is the only hit I've gotten for the symptoms when searching online.  I updated the bios of my MSI board (x370 SLI PLUS) today to one that mentions "Update AGESA Code 1.0.0.4C" in its patch notes, and immediately started seeing a long hang during bootup with the same sort of messages as the OP.  It eventually boots on its own (or ctrl-C to move on early), but udev is a broken mess when doing so, spawning 30+ processes and frequently causing spam in dmesg about systemd-udevd hanging for over 120 seconds.

Unfortunately I'm not able to downgrade the bios back to a usable version because the BIOS-based flash won't allow downgrading, but I did discover a workaround that might also be relevant to figuring out what's happening.  I have a habit of not removing old kernels after updating, so I was able to experiment with a few and found that 4.14.13 has no issues, but 4.16.12 and 4.17.8 both exhibit the broken behaviour.  I don't know if it's an AGESA problem or a kernel bug, but somewhere between 4.14.13 and 4.16.12 something changed in the kernel that is making something break horribly.

Also, I don't know if the OP ever tried getting help on the L1techs forum, but I searched there myself and saw that a few of them noticed something I also did:  the hardware device at the beginning of those errors is listed as AMD's "Encryption Controller", managed by driver "ccp".  It's used for hardware encryption but apparently is also related to AMD's Platform Security Processor (PSP).  Kernel 4.14 is when they first started adding support for the PSP part, so maybe incomplete support for it is why that one works okay for me.  Anyway, one person claims the problem went away when using a kernel compiled with CONFIG_CRYPTO_DEV_SP_PSP=n.  They didn't mention virtualisation or any negative effects, so YMMV there.  

For now, I'm just going to keep using the old 4.14 kernel I have and watch for a fix.  I got lucky by still having that kernel around, because it's in a sweet spot of being barely new enough to have the nested page table (NPT) bug fix (which is a big deal for GPU passthrough to a VM, which I use heavily), but is old enough to not be affected by whatever is breaking things.  

Neither option (disabling the feature in a kernel compile and hoping it doesn't affect anything important, or using a 4.14 kernel) is a good solution, but I'm mentioning everything I've found on the problem so far in case it helps anyone else with finding a workaround or reporting the problem.  This situation sucks, but hopefully it gets noticed and fixed soon.

I have the same issue on my AB350 Pro4 with Ryzen 5 2600 after updating BIOS from 4.70 to 5.00 version. It doesn't reproduce on Arch Linux, only on Fedora.

EDIT: BIOS 4.90 is working fine, so the issue is in the latest 5.00 version. Interesting, that this BIOS and 1.50 for X470 both have AGESA PinnaclePI-AM4_1.0.0.4. Maybe this is the reason.

Old BIOS 7B79v13 works fine. Latest BIOS 7B79v14 fails exactly the same way.

Thx for your reply. I will head over to the forums you mentioned and see if someone can help me...

Greetings from Lower Bavaria

Tobi