Good description and hardware debugging. A google search suggest a bios bug in your case, start by disabling:
Global C-state control
in bios, and see what happens.
Actually, the message seems harmless, you haven’t noticed nothing unusual, but you’ll never know.
Keep us informed.
As you have the same error (exactly the same?) across kernels and distributions, it has to be definitely a hardware problem, maybe the motherboard or the cpu, some pins bent etc.
Here https://is.gd/tUobwo is a good discussion on the subject.
You could try running a single memory module every time and see what happens, because of:
Bank 31: ffffffffffffffff
yet it sounds strange.
I was in contact with two other guys who had exactly the same error, with the same memory bank. Yet we all had different motherboard manufacturers, ram producers, and different versions of the latest zen 4 generation cpus.
I would say that the probability that we bend the same cpu pins to get the same error is fairly close to zero…
In an other Arch thread they were mentioning changing the bootloader to load the amd-ucode before the initramfs. But as the microcode mentioned in my error is the same as the one loaded by the kernel later on (as per journalctl), I don’t know if that would change anything.
This resembles me to problems that some people had with gen1 Ryzen and linux. It turned out eventually to be a glitch in silicon for first products, which were replaced by amd:
I still do not understand whether you have encountered other problems besides that error message, which is sometimes actually harmless.
In any case, parallel to other testing, I would write to Asrock and AMD informing them what is going on, and ask the two other guys to do the same.
I would also try other live distributions, with older kernels, in case it is a software problem.
I haven’t encountered any issues so far, but at the price point of my system, I don’t want to risk something showing up down the line once the hardware happens to be out of warranty. Better safe than sorry.