AMD Ryzen Random Reboots issue

loups · 2026-06-19 07:55:24

After not having any issues with my current installation, my computer now just reboots after a few seconds after logging into KDE. (Been using ONLY arch for 2+ years and this installation is about a year old by now. Windows never touched this computer.)
It's considerably slower on the login screen already, and takes a while to finish loading the desktop. After that, it doesn't take long for the screen to go black and the whole system to reboot, getting into this loop.

For reference, my system is
CPU: Ryzen 5 5600
GPU: 7700xt
RAM: 2x16gb DDR4
Motherboard: B550M PRO-VDH WIFI (MS-7C95)

Of course, I took some pictures of the error that comes up after reboot and it basically reads as follows:

[Hardware error]: System Fatal Error
[Hardware error]: CPU :4 (19:21:0) MC5_STATUS [...]
[Hardware error]: Error Addr:0x01ffffffc05d33b2
[Hardware error]: IPID:0x000500b00[...], Syndrome: 0x000000004
[Hardware error]: Execution Unit Ext. Error Code: 0
[Hardware error]: cache level: RESV, tx: GEN, mem-tx: GEN

Not writing everything down (as noted by my use of [...]), but that's the gist of it (the values and numbers may vary slightly). Of course, after some research I noticed that the problem matches the description of https://wiki.archlinux.org/title/Ryzen#Random_reboots, so I started taking some measures to troubleshoot it, given that I never messed with these things (been running it stock ever since I built this PC). First things first, I updated my BIOS. Then I Tried to change my curve optimizer with an offset of +4, as suggested in the wiki. Nothing changed. Then I Went onto section 4.2, which still matched what is happening to me, and applied PBO+4 or +6. Nothing changed. Then I Came here to the forums, and checked some threads from people that had the same or similar issue and saw some suggestions to also slightly underclock the CPU by -50. Nothing changed.

Might also be good to note that before I tried messing with all that, I also tried to boot into the arch ISO without any success. Also, for good measure, tried doing the same but with linux mint's and nothing worked still. So yeah, I'm pretty much completely locked out of my main system and don't really know what to do right now other than ask here.

If it helps, last I updated my computer was on the 4th of this month.

seth · 2026-06-19 11:53:17

Increase the offset drastically or disable PBO altogether, disable the c-states ("processor.max_cstate=1") and

It's considerably slower on the login screen already, and takes a while to finish loading the desktop.

please post the complete journal of the previous (crashing or ideally try to properly reboot the system immediately) boot.

sudo journalctl -b -1 | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

Does the system also crash out of a, say, icewm or openbox session?

loups · 2026-06-20 03:37:42

Ok, so...
- C-States were already disabled. Forgot to mention, but was also something that I tried when looking for suggestions yesterday;
- Tried disabling PBO completely, also didn't work;
- Changed the offset from 4->8, also didn't work. Also tried changing from 8->12, but it still had no effect. I don't really how how drastic i have to be...;
- Tried to... properly reboot the system? If by that you mean trying to reboot the computer before the whole thing crashing down and rebooting yeah, ok, I gave that a try and there's no time, even if I do it on login screen;
- Given the nature of what happens, and as I mentioned in the original post, I don't see how I can take time to open the terminal, type all that and get a complete journal of a previous crash. Best I can do is take a picture of the thing as it boots after it crashes&reboots and shows some error messages;
- Also I only have KDE installed, so I don't know if I changed to another DE after boot it would change anything.
What appears on the screen upon reboot is:

[Hardware Error]: System Fatal error
[Hardware Error]: CPU:9 (19:21:0) MC5_STATUS(IUEIMiscVlAddrVIPCClTCClSyndVl-l-l-): 0xbca0000000000108
[Hardware Error]: Error Addr: 0x01ffffffc07e3360
[Hardware Error]: IPID: 0x000500b000000000, Syndrome: 0x000000004d000000
[Hardware Error]: Execution Unit Ext. Error Code: 0
[Hardware Error]: cache level: RESV, rx: GEN, mem-tx: GEN
Booting initrd of Arch Linux
(booting messages)
After it finishes up cleaning up and shutting down daemons, by the way, it spends about a minute and a half doing:
A stop job is running for Rule-Based Manager for Device Events and Files ( 0s / 1min 30s)
I don't know if describing that also helps in any way, but there it is.

One other thing I noticed is that my issue might be similar to This other post. Or at least that we're in a similar spot.

seth · 2026-06-20 06:37:08

- Given the nature of what happens, and as I mentioned in the original post, I don't see how I can take time to open the terminal, type all that and get a complete journal of a previous crash. Best I can do is take a picture of the thing as it boots after it crashes&reboots and shows some error messages;

Only boot the multi-user.target (2nd link below) hope it doesn't crash there and post the journal (of the previous boot, "-1") from there,

loups · 2026-06-20 13:54:16

Ok, managed to boot without GUI and I just can't type that fast enough before crashing. Counted and it only lasts about 54 seconds to crash in that state, which also probably matches the others.

seth · 2026-06-20 14:10:23

Are the fans running?
Can you check the temperatures?
Does "maxcpus=1" or "maxcpus=0" allow stable use?

If it helps, last I updated my computer was on the 4th of this month.

Does this coincide with the beginning of the problems?

loups · 2026-06-20 15:01:53

I am still a bit slow and learning my way through this, so sorry for not coming up with this before, but... I had an idea. Had enough time to at least type:

 journalctl -b -1 | grep -i error

and got this back (took a picture of it XD):

archlinux kernel: x86/amd: Previous system reset reason (0x08000800): an uncorrected error caused a data fabric sync flood event
here the same system fatal error cpu thing from before, then:
archlinux kernel: RAS: Correctable Errors collector initialized.
archlinux kernel: usb 1-9: device descriptor read/64, error -110
archlinux kernel: usb 1-9: device descriptor read/64, error -110
archlinux kernel: usb 1-9: device descriptor read/64, error -110
archlinux kernel: usb 1-9: device descriptor read/64, error -110
archlinux kernel: usb 1-9: device not accepting address 7, error -71
archlinux kernel: usb 1-9: device not accepting address 8, error -71
<my username> kernel: faux_driver regulatory: Direct firmware load for regulatory.db failed with error -2
<my username> wireplumber[587]: default: Failed to get percentage from UPower: org.freedesktop.Dbus.Error.NameHasNoOwner

I don't know if it's useful, but I hope it is. There was nothing else and after that it crashed again, of course.

Also, after logging in, I checked that my current kernel is 7.0.11-arch1-1, and the time I last updated my computer (4th of this month, as stated before) DOES NOT coincide with the time this issue came up. It only started happening as of two days ago, on the 18th, after I came back home and tried booting the PC again after work.

I'll try your latest suggestions after I come back from lunch, but from my time meddling with options from the motherboard I can say that there was nothing strange about temperatures or anything. All around 50C, very stable (as the CPU has its own cooler, not the stock one that comes with it). As for fans, there's only one fan (from the case itself, not from the CPU or anywhere else) that hasn't been working for a while and I haven't had time to get it fixed. The two others adjacent to it have been working just fine, so I never took it too seriously. Maybe I should see if I can unplug it? Thing is, as I said, it haven't been working for a while and there was never any issue, so I don't know how this whole problem could be related to that...

seth · 2026-06-20 19:23:00

I don't know if it's useful

Unfortunately not - and hardware errors will unlikely to be logged as "error" of this kind

there's only one fan (from the case itself, not from the CPU or anywhere else) that hasn't been working for a while and I haven't had time to get it fixed

The RAM could overheat (it tolerates way less temperature than the CPU)

Thing is, as I said, it haven't been working for a while … It only started happening as of two days ago, on the 18th

Not asking you to dox yourself, but where do you live? Cause here the temperatures rose from 14°C to 32°C in the last three days …

Can you open the case and blow a room fan at the system?

loups · 2026-06-20 19:42:58

Tried opening the case and putting my fan at full blast towards it and nothing changed. Might just contact someone I know who can test the internal components for possible hardware failure, because that might just be the issue I'm having, by the looks of it. Just gotta hope that if that's actually the case, it doesn't end up being faulty RAM because that's gonna cost me a lot right now LMAO.
Watching the temperatures in the BIOS here and everything is super stable and below 40C (fan is still blasting at it, and without it wouldn't be much far from this either). I know that when everything boots and such it's a different environment, but still... Anyways, it's just kinda crazy to me that everything is so stable here but can't last a minute normally.
I'll get back to this once I investigate further. Thanks for the help so far!

seth · 2026-06-20 19:46:37

Can you boot and run https://wiki.archlinux.org/title/Stress … Memtest86+ ?
You could try to remove either of the two DIMMs and see whether that stabilizes it.
Booting w/ "maxcpus=0" didn't help?

Tiikerihai · 2026-06-21 10:55:15

So out of curiosity, did you try booting into a live Linux environment at all? It doesn't seem like a software issue, but there's no harm in trying to boot either the Arch Linux installation medium or some other live Linux image which has KDE.
The things I would try to stabilize this would be for example setting memory clocks to a lame JEDEC spec like 2133 or whatever is available for your memory and board, making sure to avoid any OC (XMP, DOCP or EXPO), setting processor multiplier to like 20 or whatever is available that's below 35, disabling all the power saving crap that lowers voltages, removing all superfluous hardware not needed to turn on the computer. If it's really a hardware issue, you'd have to start physically replacing parts to test what's still working.
Memtest is indeed a good thing to try.

seth · 2026-06-21 11:41:51

So out of curiosity, did you try booting into a live Linux environment at all?

The OP wrote:

Also, for good measure, tried doing the same but with linux mint's and nothing worked still. So yeah, I'm pretty much completely locked out of my main system

loups · 2026-06-21 12:12:09

Yeah, I tried to boot into both arch iso to debug from there and linux mint's image and both crashed.
Been running memtest86+ for about 15h30min as of writing this, and nothing wrong so far. 14 passes, 0 errors. Should I call it for now or keep going in fear of having something wrong down the line?

seth wrote:

Booting w/ "maxcpus=0" didn't help?

Tried finding that on the motherboard options and didn't find anything. Unless it's on grub boot options, like your How to boot w/o GUI thing is as well. I'll look into it once memtest is done.
Will also try the other, newer suggestions.

Last edited by loups (2026-06-21 12:14:06)

seth · 2026-06-21 12:20:59

it's on grub boot options

The parameter will disable SMP and run the system only on a single core.

Been running memtest86+ for about 15h30min as of writing this

It's unlikely to be directly related to temperatures or CPU/RAM then - do you have a spare or onboard GPU?
Have you tried reseating that and checked its power supply (also 6/8-pin dedicated)?

loups · 2026-06-21 13:25:43

Ok, writing this as I test things out...
Setting

 maxcpus=0

on grub only made things quite slow (as expected) and it still crashed anyways.
I only have a 7+ year old 3gb 1060 that also having issues last I tried it on my previous computer, as far as I can tell. I would try to reseat it (my current GPU is a 7700XT), but it's quite bulky and I fear messing something up, quite honestly. No matter what, I'll take the whole computer for someone to take a look at it tomorrow, so that will probably be done then.

Tiikerihai wrote:

The things I would try to stabilize this would be for example setting memory clocks to a lame JEDEC spec like 2133 or whatever is available for your memory and board

Tried lowering memory speed from 3500 to 2400 (there was 2133 as well), disabled some CPU overclocking stuff like PBO, put it back to normal clock speed (from 3450 to 3500) and such. Was about to write how it failed as well, but things booted super fast and it's now running super smoothly, no crashes so far. So... I guess that was it then? Maybe I'll try to check some lower, but not 1100 lower RAM clock speeds...
Trying it with 3000MHz DRAM speed now. This also seems to work just fine.
Will try 3400MHz now. Doesn't seem to be any issues either.
Welp, I guess this was it then?

seth · 2026-06-21 13:30:34

I only have a 7+ year old 3gb 1060 that also having issues last I tried it on my previous computer

The "hardware error reboot" kind of issues? (Everything else doesn't matter for us to figure whether the GPU is the problem)

loups · 2026-06-21 13:42:24

seth wrote:

The "hardware error reboot" kind of issues? (Everything else doesn't matter for us to figure whether the GPU is the problem)

Well, last time that I tried opening my previous computer it was more like the "boots up but doesn't show anything on the screen" type of issue. Couldn't figure out whether it was from GPU that was getting too old or beaten up or motherboard or something else, so it's safe to say that whatever is there requires proper hardware testing before being salvaged to be used anywhere else.
Anyways, as I said in my previous post, simply changing the clock speeds of the RAM seem to have fixed the issue. I am 17 minutes deep in this current session on my computer and it's been running just fine. I'll report back here if something strange happens from now on.

Tiikerihai · 2026-06-21 15:34:31

loups wrote:

Welp, I guess this was it then?

Were you previously using XMP/DOCP for memory? When I enable EXPO on my zen 5 system, it activates ultra high voltages for the MC and VDIMM. It's possible that the memory controller got cooked over time. Usually JEDEC profiles have really loose timings, so even if you have similar clocks as before it's gonna be much more stable because the timings are really bad unless you either do them manually or activate the overclock with XMP/DOCP/EXPO. In any case, it's good if it's just a cooked memory controller that can't achieve high performance anymore. That means you can probably continue without replacing anything. That said, it's still overclocked even now, since the maximum standard for DDR4 is just 3200Mhz, I'm pretty sure.
Really bad performance is actually pretty common with unstable memory. I'm surprised it passed memtest86. I have no idea how that's possible. Then again, my computer did also pass memtest86 with unstable memory so I guess sometimes it do be like that.

loups · 2026-06-22 19:27:58

I just double checked after turning on my computer and on the motherboard BIOS, on the ram name it says XMP 3600, and since I never touched it, it was probably at the XMP profile either at 3600 or 3500.
Bumped it down to 3200 and will be happy with that for as long as this computer can keep going XD, as it will probably never make a big difference to me.
For reference, my ram kit is a corsair 2x16gb 3600mhz.
Also, no crashes since I changed the RAM speeds.

Tiikerihai · 2026-06-22 22:27:54

I'd recommend checking your voltages against defaults just in case. Unless you've cleared your BIOS/applied a JEDEC profile (Idk actually if that leaves residual XMP profile voltages) and never loaded XMP after that, there may be very high voltages on various CPU components which can kill your CPU over time. Lower memory speeds wouldn't normally need high voltages. Or just leave it be if you don't care, if it works it works.

Last edited by Tiikerihai (2026-06-22 22:30:57)

loups · 2026-06-24 09:50:53

Double checked and as far as I know, all CPU voltages are on default. I hope there won't be any problems from now on. Thanks for all the help and tips!
(I don't know how to close the topic, so I'll just leave it be from now on o7 XD)

Last edited by loups (2026-06-24 09:51:37)

gerliczkowalczuk · 2026-06-24 10:42:59

My guess would be that either the memory controller or the RAM itself is no longer fully stable (possibly due to physical degradation) at the XMP frequency. Running the memory at 3200 MHz is perfectly reasonable if the system is stable there.

Glad you managed to find the cause.

Last edited by gerliczkowalczuk (2026-06-24 10:45:38)

Arch Linux

#1 2026-06-19 07:55:24

AMD Ryzen Random Reboots issue

#2 2026-06-19 11:53:17

Re: AMD Ryzen Random Reboots issue

#3 2026-06-20 03:37:42

Re: AMD Ryzen Random Reboots issue

#4 2026-06-20 06:37:08

Re: AMD Ryzen Random Reboots issue

#5 2026-06-20 13:54:16

Re: AMD Ryzen Random Reboots issue

#6 2026-06-20 14:10:23

Re: AMD Ryzen Random Reboots issue

#7 2026-06-20 15:01:53

Re: AMD Ryzen Random Reboots issue

#8 2026-06-20 19:23:00

Re: AMD Ryzen Random Reboots issue

#9 2026-06-20 19:42:58

Re: AMD Ryzen Random Reboots issue

#10 2026-06-20 19:46:37

Re: AMD Ryzen Random Reboots issue

#11 2026-06-21 10:55:15

Re: AMD Ryzen Random Reboots issue

#12 2026-06-21 11:41:51

Re: AMD Ryzen Random Reboots issue

#13 2026-06-21 12:12:09

Re: AMD Ryzen Random Reboots issue

#14 2026-06-21 12:20:59

Re: AMD Ryzen Random Reboots issue

#15 2026-06-21 13:25:43

Re: AMD Ryzen Random Reboots issue

#16 2026-06-21 13:30:34

Re: AMD Ryzen Random Reboots issue

#17 2026-06-21 13:42:24

Re: AMD Ryzen Random Reboots issue

#18 2026-06-21 15:34:31

Re: AMD Ryzen Random Reboots issue

#19 2026-06-22 19:27:58

Re: AMD Ryzen Random Reboots issue

#20 2026-06-22 22:27:54

Re: AMD Ryzen Random Reboots issue

#21 2026-06-24 09:50:53

Re: AMD Ryzen Random Reboots issue

#22 2026-06-24 10:42:59

Re: AMD Ryzen Random Reboots issue

Board footer