now i just have to wait for the crash...

Just to confirm that with those syslog server settings the persistent syslog will be written to the ‘Backup’ share and this should be posted after the crash.

its writing to syslog-127.0.0.1.log on my backup share

just waiting for the system to freeze now.

Thanks for the patience and help.

ok this time the parity check completed and it rebooted itself....

syslog-127.0.0.1.log

6 hours ago, Ebein said:

and it rebooted itself....

Server rebooting by itself is alsmost açlways a hardware issue, and not surprisingly,, there's nothing relevant logged, I would start by running memtest, or trying a different PSU

I checked Fix Common Problems this morning and this showed up.

Making a Thumbdrive for memtest.

Ran memtest, and passed, will run it again, anything else to check, CPU test, PS?

any suggestions?

just need a stable system =/

9 minutes ago, Ebein said:

Ran memtest, and passed, will run it again, anything else to check, CPU test, PS?

any suggestions?

just need a stable system =/

Just to confirm you ran the memtest for a minimum of 24 hours?

i ran it for 6, and started the next one, Ill post tomorrow aftter its run a few more times

Because memtest is only definitive if it finds errors, since you have multiple RAM sticks, you can also try using the server with just one, if the same try with the other one, that will basically rule out bad RAM.

ive run Memtest for about 24 hours now, passed the full suite 3 times, going on a 4th atm. I almost hoped it would be ram issue, that would be an easy (if expensive) replacemeent.

Not sure what the issue is at this point, why does everything work fine during a parity check, then stop a while after its done.

Fresh syslog and diagnostics ...

ava-diagnostics-20260719-2333.zip ava-syslog-20260720-0335.zip

That is the same syslog that is in your diagnostics. You need to post this one

On 7/16/2026 at 1:26 PM, Ebein said:

its writing to syslog-127.0.0.1.log on my backup share

4 hours ago, Ebein said:

why does everything work fine during a parity check, then stop a while after its done.

That is exactly the issue that sleep states have with Ryzen CPU, as described in the FAQ link posted earlier: when the CPU is not in use, it crashes.

I disabled the C-states in BIOS, isnt that supposed to fix the ryzen crashes? Is that with all ryzen CPU's or just 1st gen? If a new 5000 series chip will fix the issue I'll order one today.

Here is the syslog from the backup.

syslog-127.0.0.1.log

I dont want to give a false impression but I've been running a Ryzen 7 5800X in my server for years now and have not had these issues. With that said Im running a B550 motherboard which is a newer chipset and different bios which could also play a role in your issues.

I suspect it's the ancient 1800X CPU but I would hate for you to go spend money on something that doesn't fix your issue.

1st gen ryzen was pretty hit/miss

Edited Monday at 02:23 PM2 days by MowMdown

1 hour ago, Ebein said:

disabled the C-states in BIOS, isnt that supposed to fix the ryzen crashes?

It should just double-check they are actually disabled, or using the recommended setting, but there may be other things involved.

i think I need a new MB/cpu, i set the c-state to disabled, save, and reboot and its back to auto again.

I'll be buying a ryzen 5000 cpu, i have plenty of DDR4 ram, so I will reuse it, any issues with those or boards i should avoid?

Thanks for all the help!

New PS, B550 mb, 5700G cpu on the way. will set it all up friday.