abc123

Current change: Updated to utilize Profile and XMP Profile for ram to get correct timings, then changed the speed down to 2666, to match the required speed setting but also hopefully to make the ram more stable, it has currently lasted - BIOS: Enabled power boost - BIOS: Curve +7 Uptime 1 hour 25 minutes However, I've had intermittent stability for over 5 days.

Still crashing... Tried: - Updating bios to 5.60 https://www.asrock.com/mb/AMD/X570 Taichi/index.asp#BIOS - Removing two sticks of ram - Trying the other two sticks of ram - trying different ram slots with different 2 sticks Nothing seems to be resolving the issue, system is now unstable after less than 1 hour. - BIOS: Disable power boost - BIOS: Disable global c-state - BIOS: Power idle control = Typical current idle - BIOS: IMMOU enabled - BIOS: Curve +6 - BIOS: RAM 1.35V speed 2666

Just enabled eco mode and bumped to +9… going to research other settings from above post as perhaps something else is up, not seeing anything in logs still

Crashing is back up to +8 on the curved now

Crashing appears to be resolved, I believe +6 postive curve modifier was the solution for me. I already had - BIOS: Disable global c-state - BIOS: Power idle control = Typical current idle I don't know what happened for the stuttering, also I changed the Docker Network type to ipvlan, and setup a VLAN on my router to move all the unraid server + containers to 192.168.13.2-255

Looks like the +6 positive curve modifier got it stable, no crashing. There was a weird stutter...tower-syslog-20250313-1352.zip Where the server didn't load everything but still was responding some to the HTTP requests?

Bumped up to +6 on the curve for silicon lottery mention, also already had typical idle current set in bios, since server was stable before update + giving all cpu cores to unraid through the boot command, I believe this is a CPU issue I wasn’t hitting when only running half the cores. ill continue boosting the curve to test, current setting +6

4. [running server now start time 5/12/25 5:39pm EST] Test Still appears to be crashing after <5 minutes. Attached new logs syslogs* files from Flash write, others are from the logs tower-syslog-20250312-2147.zip tower-syslog-previous-20250312-2146.zip syslog syslog-previous tower-diagnostics-20250312-1749.zip

I should mention I made one other change, I used to run a Window VM for gaming and I had half the CPU cores pinned to not be used by unraid, I disabled this, likely causing this instability.

Alright, what I am parsing from the above post. 1. [done global c-state disabled] In bios check for disabling c-states 2. [done Advanced -> AMD Overclocking -> Curve +4] Change bios with ``` To solve this problem you need to supply higher voltage to your CPU so that it is stable when running at peak frequencies. The easiest way to achieve this is to use the AMD curve optimiser which is accessible via your motherboard's UEFI. Access it and put a positive offset of 4 points, which will increase the voltage your CPU is getting at higher loads. It will limit overclocking potential due to higher heat dissipation requirements, but it will run stable. ``` 3. [was already disabled changed speed from 2377 to 2666] Make sure XMP is disabled and instead use slower supported speeds 4. [running server now start time 5/12/25 5:39pm EST] Test 5. if still having issues, try different ram stick pairs 6. next, ``` Reducing frequencies to within non-overclocked standards and increasing voltages of CPU or RAM helps, but might not fix the issue. A potential fix is to update the UEFI (also misnamed "BIOS updates"), and then apply the PBO+4 curve for more stability on higher frequencies. Per silicon lottery, some CPUs might need +6 or higher offsets. ``` 7. next, not sure how to do this one, but I'll take a gander. ``` This seems to be related to the C6 c-state, that does not seem to be well supported (if at all) in Linux. To fix this issue, go into UEFI Setup and search for an option labelled something like this: "Power idle control". Change its value to "Typical current idle". Note that these names are dependent on what the motherboard manufacturer calls them, so they may be a little different in your particular case. Other less ideal solutions include disabling c-states in the UEFI Setup or adding processor.max_cstate=1 to your kernel command line arguments. ```

syslog from the dumped file, maybe it has the crash in it.syslog-192.168.1.50.log Running in safe mode with GUI is somehow more stable today...

tower-diagnostics-20250312-0833.ziptower-syslog-20250312-1234.zip Captured the diagnostics and syslog.

Alright so it isn’t the ram, any help would be appreciated

Ran in safe mode with no gui and it still crashed (before I could pull the logs), running a full memory test now to cehck if there are perhaps issues there.

Looks like fast boot was already disabled, under that CSM I enabled it for UEFI mode on both...maybe that will help resolve the annoying moving USB stick