Image credit: Aorus Spain
DocTB, a former reviewer best known for his development work for CPU-Z’s validator, recently started a discussion around the news of 12900k breaking 8 GHZ in extreme overclocking, and how this was extremely implausible to do.
Simply put, due to an exploit in Alder Lake it was possible to let the CPU report a differently set frequency than it was actually running at that point. This made it possible early on to validate 8/9/10/12+ GHz overclocks while running a much lower frequency physically. This was patched by Intel, but not on a silicon level. CPU-Z has tried to counter this invalid result in version 1.98. From here, overclocking records ranged up to 7 GHz all core stable or in a “suicide run” to 7.5-7.6 GHz on a single core. This is of course very impressive, and was often beaten by a few megahertz with binning, but then suddenly… an 8 GHz record shows up on the validator.
In a follow-up a few days later, it was found that the exploit could still be executed, even when patched by Intel with their microcode. There now is a new internal version of CPU-Z that can also detect this version of the exploit, but the 8 GHz record that suddenly showed up has proven to be fake, as the actual clock was 5683.94 MHz using a new analysis algorithm. This was also done with 5950x at launch, where a fake 6362.16 MHz record was shown.
Below, a few quotes of the tweets from DocTB:
We started to see the first “hard-core” ADL overclocking in early September. Almost immediately, a silicon errata was found with ratio set at > 63. In some rare conditions, the internal CPU PLL fails to lock and remains at the previously set ratio while reporting the new one. Quickly, we received many 8/9/10/12+ GHz fake “overclocking” on early Alder Lake samples. As it was way too late to patch the issue on silicon (and not really a big thing for 99.99999% of Intel’s customers), Intel team worked their ass off to found a fix. Congratz to them! The fix was implemented in a new microcode update (0x12) by adding a new HW register called FLL_OC_MODE. When enabled and set properly, the internal CPU insure that the PLL is correctly locked with ratio > 63. The report for FLL_OC_MODE was implemented in CPU-Z 1.98. On the validator side, about a month ago, I’ve added a lot of additional checks (microcode version, core throttling, fll_oc_mode register checking) to invalidate the already-posted entries that exploited the issue. Everyone played quite a lot just for fun, so it was necessary.
For the last 4 weeks, all big overclockers linked to motherboards makers worked seriously on ADL with these new fair rules. The overall consensus was that full all-cores benchmark stability is possible at around 7 GHz and “suicide run” on single core up to 7.5-7.6 GHz. WR records between 7.5 and 7.6 GHz were set and broken almost each days, by a few MHz at most. many overclockers tried a lot of CPU (20/50/100+ samples) to grab the golden ones able to reach these frequencies … or a few MHz higher.
Then suddenly, some days ago, we saw a unique 8 GHz validation popping from nowhere. Knowing that tens of overclockers tested hundreds of CPUs on a bunch of motherboards while all struggling around 7.5 GHz, that’s quite suspicious at least… Was the PLL lock bug back, this time on a way we can’t detect as it passes all internal checks? Seems legit. Technically, we can think about a way to trick the CPU if we have access to BIOS source code (some overclockers working with MB makers have them).
It basically involve first messing with CPU ratio, then upgrade the microcode, and finally set the FLL_OC_MODE to enabled, all at boot time. That could led to a situation where the flag is enabled but the CPU still at a much lower ratio than reported. In all cases, it’s necessarily intentional because this involve a lot of complex operations and messing with early boot stages. Intel team worked on this and found a way to check if the PLL is really locked by messing quite badly with some performance MSRs.
Problem: if the PLL is not locked, the whole CPU will hard-lock immediately, needing a reboot to recover. That’s something we can’t implement in CPU-Z because all Windows crashes are reported by Microsoft’s mandatory telemetry and we can be banned by Windows Defender for that. There’s nothing we can do on our side right now.The issue is now on Intel’s hands, needing a new hardware stepping or maybe another microcode patch. Solving such a niche issue to prevent ppls messing with BIOS source code is a real challenge and probably not on the top list.
1/ Despite several requests over the past weeks, we never received any evidence that the CPU really reached 8 GHz. No other overclocker has been able to approach that frequency so far and the original submitter confirmed he’s not able to reproduce this anymore.
2/ We are now aware of a method that can be used to exploit a hardware errata on Alder Lake CPUs, despite the microcode fix added by Intel. It involves low-level control of the boot process. We’re testing a new internal CPU-Z revision able to detect that trick.
3/ A very similar case occurred for the launch of the Ryzen 9 5950X, involving the same players. Until earlier today, many OC website reported a 6362.16 MHz World Record for this CPU.
Using the new analysis algorithm on that old CPU-Z submission datas, we can now confirm that the real actual clock was 5683.94 MHz. That dump was already manually rejected soon after submission due a known exploit on AMD Vermeer CPUs at launch. Every CPU-Z Validations contains a lot of internal CPU configuration registers actually unknown and/or unchecked. We’re working for a way to distinguish the bugged ones and we will reprocess all ADL records if we find one.
