March 24, 20251 yr Hello all, It appears my Unraid (v7) crashed this morning. Ran the "fix common problem" scan; with the following error Machine Check Events detected on your server Diagnostics attached. I'd appreciate your help in identifying the root cause. Thank you, -Adam fx8350-diagnostics-20250324-1310.zip
March 25, 20251 yr Author Mar 24 05:19:32 FX8350 kernel: microcode: microcode updated early to new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU0: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU1: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU2: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU4: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU3: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU6: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU8: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU7: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU12: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: mce: [Hardware Error]: Machine check events logged Mar 24 05:19:32 FX8350 kernel: microcode: CPU13: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU1: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU3: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU9: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU11: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU6: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU8: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU12: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU14: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU7: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU13: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: mce: [Hardware Error]: CPU 2: Machine Check: 0 Bank 5: bea0000001000108 Mar 24 05:19:32 FX8350 kernel: mce: [Hardware Error]: TSC 0 ADDR ffffff81a0a012 MISC d012000100000000 SYND 4d000000 IPID 500b000000000 Mar 24 05:19:32 FX8350 kernel: mce: [Hardware Error]: PROCESSOR 2:a20f12 TIME 1742818730 SOCKET 0 APIC 4 microcode a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU5: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU2: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU10: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU15: patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU9: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU11: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU14: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU5: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU15: new patch_level=0x0a201210 Mar 24 05:19:32 FX8350 kernel: microcode: CPU10: new patch_level=0x0a201210
March 25, 20251 yr Community Expert if you turn off the vm does it stop? -You may have pined cpus between VMs and dockers to cause this. I'm not seeing much in the diag.. Based on qemu and other maxed on the processor... I also recommend stopping the system, reboot and at the reboot screen to run meetest. just to make sure this is not memory controller / ram failures. Before the reboot in terminal type mcelog mcelog whats the output?
March 25, 20251 yr Author Memtest report attached, where would I retrieve the mce log after reboot? thx!!MemTest86-Report-20250325-044002.html
March 25, 20251 yr Author I found two pending BIOS patches for the board. Installed both before running memtest. Lastly, Docker is not enabled on this node. Thanks again for sharing your insight. Edited March 25, 20251 yr by adam5622
March 25, 20251 yr Author root@FX8350:~# mcelog mcelog: ERROR: AMD Processor family 25: mcelog does not support this processor. Please use the edac_mce_amd module instead. CPU is unsupported If it makes a difference, the hardware on this machine was upgraded a few months ago; from FX8350 to Ryzen 5800x. Edited March 25, 20251 yr by adam5622
March 25, 20251 yr Community Expert thank you for sharing. Since this is AMD. Must have ready the x370 chipset and processor wrong. mcelog wouldn't be of help here. Quote FX8350 to Ryzen 5800x. Make sure you are running the latest motherboards bios. This shouldn't be a issue unless silicon lottery you have a bad processor and or, the cpu is not tight and need to be tighter to make pin contact. Both I doubt... but throwing it out there... I would recommend boot into a windows instance and making sure that bios is up-to-date.
March 25, 20251 yr Author 1 hour ago, bmartino1 said: Make sure you are running the latest motherboards bios. This shouldn't be a issue unless silicon lottery you have a bad processor and or, the cpu is not tight and need to be tighter to make pin contact. Both I doubt... but throwing it out there... Yep, upgraded two versions on the BIOS. Re-running the parity now. So far so good.
March 26, 20251 yr Author are these results within acceptable range? The canceled check ran with auto-correct enabled, the latest scan ran without auto-correct. Edited March 26, 20251 yr by adam5622
March 26, 20251 yr Community Expert Exactly zero parity errors are in the acceptable range. Run a correcting check, which should correct those 168 errors, then run a non-correcting check, to confirm no errors remain. If that check still has errors, something needs further investigation.
March 26, 20251 yr Community Expert Solution On 3/24/2025 at 4:15 PM, adam5622 said: crashed this morning 18 hours ago, adam5622 said: Ryzen 5800x If it continues to have crashing
March 26, 20251 yr Community Expert yes, but any disk access will slow down parity check, and parity check will slow down disk access, so better if that is kept to a minimum. Ideally, your VM vdisks are on a pool and not the array, so that won't matter.
March 26, 20251 yr Community Expert 1 minute ago, trurl said: Ideally, your VM vdisks are on a pool and not the array, so that won't matter. Checking those diagnostics you posted earlier, appdata and domains have all files on pool. appdata is where individual Docker containers keep their working data. domains is where VM vdisks are kept. But... system share is all on the array. That is the most important share in this regard for Dockers/VMs, because these files are always open when Docker and/or VM Manager are enabled in Settings. Doesn't matter whether specific Dockers or VMs are running or not.
March 26, 20251 yr Author I see, so does that mean I should disable VM manager while the parity check is running? Dockers isn't used on this node, so it's already disabled.
March 26, 20251 yr Community Expert Probably won't make much difference to parity check. But you should move that share to pool later, and nothing can move open files.
March 26, 20251 yr Community Expert 1 hour ago, adam5622 said: so does that mean I should disable VM manager while the parity check is running? If you are not using the VM then do not bother. If you are using the VM then expect degraded performance while the parity check is running.
March 27, 20251 yr Author Quick update: Disabled C states in BIOS Re-Ran Parity check. The previously flagged 168 errors were fixed. Thank you all for your input & assistance in resolving this issue! This community is awesome 😁
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.