Since when did ASRock/AMD/AMI start to suck£

Thanks for the info RokeJulianLockhart.

So some more progress, at least in identifying the cause of the resets:

After compiling a custom kernel with a recent upstream patch, I am now able to identify the proximate cause of the reset:

[    2.068426] x86/amd: Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event

So it might still be a bad PSU, or the BIOS didn't quite set up the h/w properly. Keep in mind the resets are random, under almost no load, cool system temperature, and very little user activity.

At least the Linux community cares about AMD enough to dump the last-reset-reason MSR into dmesg. Patch isn't released into mainline yet, but it probably will be next release (6.16...). It is an easy backport, and I couldn't wait.

I'll have to do some more research, but it doesn't seem like this error is referring to memory...I believe the uncorrected error might be on the HT bus or something internal in the CPU...maybe a uCode patch is in order or the PSU really is flaky. And this happened with two different Ryzen 9 7900X's on two different boards (same PSU, until this one is RMA'd, which is in progress).

I wonder if AMD or ASRock is hiring? I've done more to debug this then their collective lot...maybe they can take it from here.

Yes, that points to the PSU.

zoltan wrote: I have not run any overclocking, cpu, memory, nor graphics. I do not know where to get stability tests. Even if I did, I doubt it would run on Linux, though you never know these days... I have not run memtest. Which memtest in particular (again, for Linux), or better yet, do you have a memtest.efi that I can run from the EFI shell? So, I did observe that my memory is NOT on the approved QVL for the x870 SL wifi. I have now ordered new memory (rather expensive I might add) that claims to be specifically compatible with the x870 Pro RS board _and_ x870 chipset with the AM5 Ryzen. Given that the x870 Pro RS and x870 SL wifi are same chipset (at least as far as memory is concerned), and the memory manufacturers additional claim that x870 chipset is supported (though only the x870 Pro RS board was singled-out by name), there is reason to believe that this memory should be compatible and may fix the resets. So we shall see if memory instability is causing sporadic and spontaneous resets. What would still help debug this is if ASRock and/or AMD would tell us the MMIO location (or the PCIe BDF/offset) for the last reset reason register. This should not be top-secret or even proprietary. If you don't want to hand-out the decoder sheet for the meaning, then fine, but at least I could post the value and an ASRock BIOS engineer or AMD rep. could point us in the right direction. At a minimum it would be nice to know if it was a CPU reset or a Platform reset that caused the last reset. I'm not 100% convinced that the memory may be the only culprit in these resets. The various Cx-states have also become so complicated and when intertwined with that abomination of a spec. called 'ACPI' (another demonic plot hatched by the evil that resides in Redmond) makes it so that I can't rule-out some mis-configured ACPI table trying save half-a-milliwatt over the next 20 years is accidentally and/or indirectly resetting the board. One more data point observation: with my current memory, the first reset occurs after about 3.5 - 4 days of being powered-on and running (even if idle). However, after this first spontaneous reset, the next reset occurs in about 6 - 12 hours. And it keeps getting shorter and shorter, sometimes not even being stable enough to fully boot without a reset. But, if I physically put the board in G3 state (manually unplug the dang thing), then I'm good for another 3.5 - 4 days before the next reset. I know memory and chipset maintain a few things across resets but not across full power-cycles, so maybe it is the memory. Anyway, if you could point me to the stability and memory tests, I'd be happy to run them (Linux only please, as I refuse to install viruses posing as an OS on my machines).

there is a couple stress test apps you can use in Linux - gst (GtkStressTest), stress-ng, prime95..

to have memtest as a bootloader entry in GRUB bootloader in Arch i needed to install 'memtest86+-efi' package and regenerate grub config (grub-mkconfig -o /boot/grub/grub.cfg)

i too think it might be CPU not memory. I would stress test and would try to set a POSSITIVE curve optimizer value in the BIOS (+3~5 max), giving the cpu a bit more voltage at stock speeds. Limit the wattage a lil bit below designed TDP.

> yay -Qs stress local/gst 0.7.7-1     System utility designed to stress and monitor various hardware components local/stress 1.0.7-3     A tool that stress tests your system (CPU, memory, I/O, disks) local/stress-ng 0.19.00-1     Software to stress test a computer system in various selectable ways mm@desktop /etc/grub.d > yay -Qs prime local/mprime 2:30.19.20-1     A GIMPS, distributed computing project client, dedicated to finding Mersenne primes. local/mprime-debug 2:30.19.20-1     Detached debugging symbols for mprime local/ruby-prime 0.1.3-1     Prime numbers and factorization library mm@desktop /etc/grub.d > yay -Qs memtest local/memtest86+-efi 7.20-2     Advanced memory diagnostic tool EFI version

Edited by M440 - 06 May 2025 at 1:39pm

I have not run any overclocking, cpu, memory, nor graphics.

I do not know where to get stability tests. Even if I did, I doubt it would run on Linux, though you never know these days...

I have not run memtest. Which memtest in particular (again, for Linux), or better yet, do you have a memtest.efi that I can run from the EFI shell?

So, I did observe that my memory is NOT on the approved QVL for the x870 SL wifi. I have now ordered new memory (rather expensive I might add) that claims to be specifically compatible with the x870 Pro RS board _and_ x870 chipset with the AM5 Ryzen. Given that the x870 Pro RS and x870 SL wifi are same chipset (at least as far as memory is concerned), and the memory manufacturers additional claim that x870 chipset is supported (though only the x870 Pro RS board was singled-out by name), there is reason to believe that this memory should be compatible and may fix the resets.

So we shall see if memory instability is causing sporadic and spontaneous resets.

What would still help debug this is if ASRock and/or AMD would tell us the MMIO location (or the PCIe BDF/offset) for the last reset reason register. This should not be top-secret or even proprietary. If you don't want to hand-out the decoder sheet for the meaning, then fine, but at least I could post the value and an ASRock BIOS engineer or AMD rep. could point us in the right direction. At a minimum it would be nice to know if it was a CPU reset or a Platform reset that caused the last reset.

I'm not 100% convinced that the memory may be the only culprit in these resets. The various Cx-states have also become so complicated and when intertwined with that abomination of a spec. called 'ACPI' (another demonic plot hatched by the evil that resides in Redmond) makes it so that I can't rule-out some mis-configured ACPI table trying save half-a-milliwatt over the next 20 years is accidentally and/or indirectly resetting the board.

One more data point observation: with my current memory, the first reset occurs after about 3.5 - 4 days of being powered-on and running (even if idle). However, after this first spontaneous reset, the next reset occurs in about 6 - 12 hours. And it keeps getting shorter and shorter, sometimes not even being stable enough to fully boot without a reset. But, if I physically put the board in G3 state (manually unplug the dang thing), then I'm good for another 3.5 - 4 days before the next reset. I know memory and chipset maintain a few things across resets but not across full power-cycles, so maybe it is the memory.

Anyway, if you could point me to the stability and memory tests, I'd be happy to run them (Linux only please, as I refuse to install viruses posing as an OS on my machines).