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

Might as well start documenting this somewhere, so people can be informed.

I purchased an X870SL motherboard, a Ryzen 9 7900X, and ASRock SL 850W power-supply and some Patriot Viper memory (PVVR564G600C36K).

First issue is that the power-supply doesn't support legacy SATA 3.5" hard-drives. Apparently, there is some new SSD spec. change that one of the power lines on the SATA power-cable keeps the legacy hard-drive in a powered-down/sleep state. I had to cut the outside wire from the power supply to the 3.5" hard-drive, and after that, the BIOS (and the rest of the system) discovered the legacy SATA 3.5" hard-drives. However, the drives were very unstable and even though they were rated for 6.0 Gbps, I had to throttle them to 3.0 Gbps to keep from getting hard-drive device errors.

That took about a week of research...you're welcome :-) !

But that wasn't even the worst, not by a long shot: the system resets. Magically. By itself. Not under any load. Nothing really running, CPU mostly at rest.

This spontaneous and unprovoked reset acts identically as if I had pressed the 'reset' button on the computer case, except that I didn't press it. This reset happens at random intervals averaging from 2 - 4 days. Once it ran for 6 days without a random reset, but that was the longest.

ASRock tech. support is completely useless. I called them, had a discussion, and I tried a new 870SL board with a new AMD Ryzen 9. Four days later, it reset. I opened a case with ASRock tech. support, got the usual:

---
Dear Customer,

Please DO NOT reply to this automatic mail. It is just a confirmation that we have received your email. We will have technical support personnel to contact you soon.'
---

email. Haven't heard anything since.

For this reset issue, I don't mean "Blue Screen of Death" (BSOD), nor kernel OOPS and hang...no, just straight-up board-level reset. And neither AMD (who I also called) nor ASRock want to divulge the location of the last-reset-reason register (it's mostly public knowledge on older CPU's anyway, and it will get leaked eventually). Yes, I'm a former BIOS engineer from Intel and used to build these systems and provided support for them, and supported AMI with memory reference code, but I'm just a peon now and they all get to piss all over me and tell me that it is raining. If AMI was worth half-a-sh!t, they'd have the last-reset-reason register decoded and available via a BIOS setup page diagnostic utility. But no, AMD, AMI, and ASRock all have this cover-your-corporate-AS...Rock mentality, and once they have your money, you are on your own.

So thanks for nothing. I'll be returning each of the components I purchased and upgrading to an abacus. At least that won't reset in the middle of doing nothing.

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).

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 - 8 hours 14 minutes ago at 1:39pm