Linux Thought Intel’s Bartlett Lake CPU Ran at 7 GHz — It Doesn’t, and a QNAP Engineer Fixed It

Intel recently launched the Bartlett Lake processor family — an all-P-core design aimed squarely at the embedded and edge computing market. But soon after these chips began shipping, a peculiar anomaly surfaced in Linux: the operating system was reporting a staggering maximum CPU frequency of 7.0 to 7.3 GHz for these processors, a figure that would shatter every current non-overclocked performance record. In reality, the chip’s actual maximum turbo frequency tops out at just 5.7 GHz.

The root cause was a straightforward but significant oversight: an incorrect CPU scaling factor embedded within the intel_pstate Linux kernel driver. For the Bartlett Lake P-core-only SKUs, the driver applied the wrong scaling multiplier, causing it to calculate and report a maximum frequency far beyond what the hardware is capable of. The processor itself was operating entirely normally — it was purely a software reporting error within the kernel’s CPU frequency scaling subsystem.

This week, Henry Tseng, an engineer at QNAP — the Taiwanese NAS and network appliance manufacturer — submitted a patch series to the Linux kernel mailing list targeting the intel_pstate CPU frequency scaling driver. The fix correctly sets the scaling factor for Bartlett Lake P-core processors, enabling the driver to report accurate maximum frequency data. The patch is concise, adding just a small set of lines that map the proper scaling coefficient to these specific processor SKUs.

What makes this incident particularly noteworthy is not just the bug itself, but who caught and fixed it. Bartlett Lake is Intel’s own product, designed for the embedded and edge computing segments where Linux is the dominant operating system. It is somewhat surprising that the erroneous frequency reporting was not caught during Intel’s own validation, and that the patch came from a third-party hardware vendor rather than Intel’s own kernel engineering team. QNAP, whose network-attached storage devices frequently run on Intel embedded processors under Linux, had a direct practical stake in accurate system reporting.

The phantom 7 GHz figure is notable because it represents a threshold no commercially available processor has legitimately crossed in standard operation. Today’s leading consumer CPUs have only recently broken the 6 GHz barrier under normal operating conditions — a milestone that itself took years of incremental process and microarchitectural gains to achieve. Achieving 7 GHz without exotic cooling remains firmly out of reach for current silicon.

The pace of frequency scaling has slowed considerably as transistor nodes shrink toward physical limits. At sub-7nm process geometries, phenomena such as leakage current increasingly constrain how high clock speeds can be pushed without prohibitive power and thermal costs. Meanwhile, modern high-performance CPU architectures have largely moved away from the ultra-deep pipelines that once made extreme frequencies a primary optimization target, instead focusing on wider, more efficient execution per clock cycle. Whether upcoming sub-2nm process nodes from TSMC or Intel Foundry will open new headroom for frequency improvements remains an open question in the industry.

As for Bartlett Lake itself: the all-P-core configuration — with no efficiency cores — makes it an appealing design for workloads demanding consistent, high single-threaded throughput. Despite its appeal to enthusiasts, Intel has positioned this family exclusively for the embedded market, keeping it out of consumer DIY channels for now. With the Linux driver fix in progress, these processors will at least report their actual capabilities honestly to the systems running them.