Hey everyone,

I am looking for some insight on a persistent Machine Check Exception (MCE) that is flooding my syslog and triggering audio alarms. The system has never crashed, stalled, or corrupted data, but the continuous warnings are preventing me from comfortably running a parity sync (which is now 128+ days overdue).

This started immediately after upgrading the CPU from a 3900X (which was 100% stable) to a 5950X.

The Error

The syslog is spammed every ~6 minutes with the following corrected hardware error, completely locked onto logical threads 9 and 25 (which map to the same physical Core 9 on the 5950X):

[Hardware Error]: CPU:9 ... MC3_STATUS ... 0xd820000000010150

[Hardware Error]: Decode Unit Ext. Error Code: 1, Micro-op cache data parity error.

[Hardware Error]: CPU:25 ... MC3_STATUS ... 0xd820000000010150

[Hardware Error]: Decode Unit Ext. Error Code: 1, Micro-op cache data parity error.

kernel:[Hardware Error]: Corrected error, no action required.

System Specifications

* OS: Unraid 6.12.x

* CPU: AMD Ryzen 9 5950X (Upgraded from 3900X)

* Motherboard: Gigabyte X570 GAMING X (Previously Gigabyte X570S AERO G)

* RAM: 128GB DDR4 (4x32GB)

* GPU: Nvidia Quadro P620

* HBA: LSI SAS/SATA card (2 Mini-SAS to 8 SATA)

* Storage: 10 drives housed in 3 externally powered/fanned drive cages

* PSU: 1000W (Known-good from daily driver) - Initially tested with a Thermaltake Smart 500W 80+ White.

Troubleshooting & Isolation Steps Performed

To rule out hardware defects, I methodically stripped this server down to the bare metal. The error on CPU 9 and 25 persisted through EVERY single step below:

1. Firmware & BIOS Tuning:

* Updated to the latest stable BIOS.

* Disabled XMP/DOCP (running JEDEC stock speeds).

* Set Power Supply Idle Control to Typical Current Idle.

* Disabled Global C-state Control.

* Disabled Core Performance Boost (CPB) and fTPM.

2. Component Swapping (The Hardware Elimination):

* CPU: Swapped the 5950X for a brand new, out-of-the-box 5950X.

* Motherboard: Swapped the Gigabyte AERO G for a Gigabyte X570 GAMING X.

* Power Supply: Swapped the 500W PSU for a known-good 1000W PSU to eliminate 12V transient ripple/starvation on CCD2.

* RAM: Ran Memtest86 with all 128GB populated; passed a full cycle with zero errors.

3. Software & Bare-Metal OS Isolation:

* Clean OS: Flashed a brand new, separate USB drive with a completely stock installation of Unraid 6.12.x. No plugins, no Docker containers, no VMs, no CPU pinning, no customized syslinux.cfg.

* PCIe Strip Down: Physically removed the Nvidia P620 GPU and the LSI SAS HBA.

* RAM Density Reduction: Removed two sticks of RAM, dropping to 64GB (A2 & B2) to reduce Infinity Fabric strain.

* Drive Disconnect: Completely disconnected the drive cages from the motherboard.

Current State & Conclusion

Even running a headless, stock Unraid OS on a clean USB, with a swapped motherboard, swapped CPU of same model, swapped 1000W PSU, and bare-minimum RAM, the system still reports a corrected micro-op cache parity error specifically on CPU 9 and CPU 25.

Because it is statistically impossible for two different 5950X processors to have a physical silicon defect on the exact same core across two different motherboards, I am highly confident this is not a hardware failure.

It appears to be the documented Ryzen 5000 / Linux mcelog erratum where the kernel misinterprets a normal hardware-corrected deep sleep voltage transition as a parity fault.

My question for the community:

Has anyone else fighting this specific Zen 3 "Phantom MCE" found a BIOS parameter that actually stops the polling, or is muting the error on the syslinux boot config the only accepted way to silence the false positive so I can run my parity checks in peace?

Thanks in advance for any insights!

Update:

I decided to mute the error as I could not find a logical answer and evidence that this was affecting the server in any way. System has been running straight for more than a week without any issues and all data and parity checks were successful. I even swapped a data drive and did a cache move without any issues.

For reference I used the following Linux config appending

mce=dont_log_ce

Edited May 4May 4 by hugodiaz
Readability and update on a change

Try increasing the voltage supply by a little; see here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

If issues persist, may be a bad CPU.

On 4/20/2026 at 3:03 AM, JorgeB said:

Try increasing the voltage supply by a little; see here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

If issues persist, may be a bad CPU.

I tried this as part of my testing and tshooting. I pushed it up 0.1v and error persisted.

As stated on my post these where two different CPUs on two different motherboards throwing the same error. Also with different ram modules and PSUs. And brand new flashed images of unraid on different USBs.

Don't remember seeing other reports of that, but maybe it's harmless.