On many Zen 5 desktop systems, an unstable overclock can result in a complete system freeze with no BSOD, no WHEA error and no automatic reboot.
The BIOS settings below are aimed at:
Letting the platform detect serious Data Fabric / SMU faults faster
Converting them into a reset or WHEA bugcheck instead of a silent deadlock
Disabling some deep power-saving features that can interact badly with high clocks and voltages
These options do not make an unsafe overclock “safe”, but they can make instability easier to catch and debug.
Recommended profile (AMD CBS menu)
Platform First Error Handling = Disabled
SMU and PSP Debug Mode = Disabled
Power Supply Idle Control = Typical Current Idle
Disable DF to external downstream IP Sync Flood Propagation = Sync flood enabled
Disable DF sync flood propagation = Sync flood enabled
Freeze DF module queues on error = Enabled
DF Cstates = Disabled
Platform First Error Handling = Disabled
This option controls who handles certain hardware errors first: the platform firmware (“platform first”) or the operating system.
With Platform First enabled, some PCIe / bus / RAS errors may be swallowed or mishandled by firmware, which can sometimes end up as a silent freeze under heavy overclock.
With Platform First disabled, more responsibility is pushed to the OS (WHEA on Windows), which tends to result in a visible WHEA error, BSOD, or reboot instead of a complete system lock.
Goal: Prefer a clean bugcheck or reset over a system that simply stops responding with no logs.
SMU and PSP Debug Mode = Disabled
This controls internal debug features of the SMU (System Management Unit) and PSP (Platform Security Processor).
Debug modes are useful for internal bring-up and validation, but they can change how asserts and internal errors are handled.
For daily overclocking, you want the standard, production error-handling path.
Goal: Make sure SMU/PSP behave like a retail system and do not interfere with normal watchdog / reset behavior during instability.
Power Supply Idle Control = Typical Current Idle
This setting affects how aggressively the CPU drops to very low current states at idle.
Low Current Idle can save a bit of power but is known to cause random lockups on some PSUs, especially when the CPU is heavily overclocked and rapidly jumping between idle and boost.
Typical Current Idle keeps the rails under a more stable load and avoids edge cases where the PSU briefly misbehaves at extremely low current.
Goal: Reduce random “black screen / freeze at idle or light load” that is actually a PSU + deep C-state interaction.
Disable DF to external downstream IP Sync Flood Propagation = Sync flood enabled
This controls whether a fatal Data Fabric error is propagated as a sync flood to external downstream blocks (for example, I/O IPs).
Setting “Sync flood enabled” means we allow catastrophic DF errors to propagate and trigger a global error condition.
Instead of some parts of the chip continuing to run on corrupt state, the platform treats it as fatal and can reset.
Goal: Make serious DF errors produce a hard, global fault that the system can actually respond to.
Disable DF sync flood propagation = Sync flood enabled
Similar idea, but for internal propagation of sync flood inside the Data Fabric.
“Sync flood enabled” tells the fabric to propagate that fatal condition through the whole internal network.
This again favors a deterministic reset / bugcheck over a stuck or partially-dead system.
Goal: If something goes catastrophically wrong in the fabric at high clocks, it should bring the whole system down cleanly, not leave it frozen.
Freeze DF module queues on error = Enabled
This option controls what happens to outstanding traffic in the Data Fabric once an error is detected.
With Freeze on error enabled, DF will stop its internal queues when a serious error is seen.
That increases the chances that the error-handling path (including sync flood and machine check) actually completes instead of getting lost in a storm of in-flight transactions.
Goal: Make sure DF error handling can run to completion and trigger a reset instead of hanging mid-way.
DF Cstates = Disabled
DF C-states are deep power-saving states for the Data Fabric itself.
At high fabric clocks (FCLK) and aggressive overclocks, entering and leaving deep DF power states can become a corner case.
Disabling DF C-states keeps the fabric fully awake and responsive, trading a bit of idle power for more predictable behavior.
Goal: Keep the Infinity Fabric in a stable, always-on mode during overclocking to reduce random, hard-to-reproduce lockups.
You are overclocking a Zen 5 desktop CPU and see hard-freezes under load or at idle, with no WHEA logs and no automatic reboot.
You prefer a WHEA error / BSOD / reboot over a frozen system that forces a manual power-cycle.
You are okay with slightly higher idle power and temperature in exchange for cleaner error behavior.
These options do not guarantee stability. If your voltage, clocks or memory timings are too aggressive, the system will still crash.
They simply increase the chance that an unstable configuration will fail in a visible, debuggable way instead of a silent hang.
Always combine these settings with proper stability testing (stress tests, real-world workloads) and keep in mind that every CPU and board is different.
Paolo Luppi
2025-11-19 21:13:42 +0000 UTCalpha54
2025-11-16 22:18:44 +0000 UTCalpha54
2025-11-16 22:16:10 +0000 UTCTomCatT
2025-11-16 13:39:55 +0000 UTC