A curious bug has surfaced in the Linux kernel affecting Intel Bartlett Lake processors. On systems running these chips, the kernel reports a maximum CPU frequency of 7.0 to 7.3 GHz, nearly double the actual hardware ceiling of 5.7 GHz listed in Intel’s own datasheet.
A patch series targeting the issue has now been submitted for kernel review, and it did not come from Intel. It came from a QNAP engineer.
The bug traces back to a wrong CPU frequency scaling factor being applied to Bartlett Lake processors. The Intel P-State driver, which manages CPU frequency scaling on Intel hardware, uses scaling coefficients to translate hardware counters into the clock speeds reported to the operating system.
When those coefficients are incorrect, the reported frequency diverges from reality. In this case, the divergence is large enough that Linux presents the CPU as running at speeds that are physically impossible for the hardware in question.
To understand why this matters, it helps to know what Bartlett Lake actually is.
Bartlett Lake is Intel’s latest all-P-core processor platform, built on Raptor Cove architecture and targeting the embedded computing, edge server, and Network and Edge markets where Linux is by far the dominant operating system.
It is the first Intel lineup since the pre-hybrid era to ship without efficiency cores entirely, making it an interesting product for workloads that benefit from uniform core behavior. Several SKUs are already shipping to customers in embedded system integrators like QNAP, the Taiwanese network-attached storage and edge computing company.
That context explains why a QNAP engineer is the one submitting the fix rather than someone at Intel.
Bartlett Lake hardware has been in the hands of embedded system builders for some time now, but the frequency reporting problem apparently went undetected within Intel’s own Linux kernel team until a developer working with the hardware professionally ran into it in a real deployment context.
This is not an unusual pattern in the Linux kernel ecosystem. Companies that ship products built on specific hardware often end up contributing fixes for issues that the silicon vendor’s own engineers missed or did not prioritize.
The practical consequences of the wrong frequency report depend on the workload.
Most Linux applications do not directly act on the cpuinfo_max_freq value. They ask the scheduler and the power management subsystem to run the CPU at a certain performance level and let those layers handle the hardware.
In those cases, the incorrect report is cosmetic: it looks wrong in tools like cpufreq-info or lscpu, but actual clock behavior is unaffected. The more significant risk involves software that reads cpuinfo_max_freq and uses it to make decisions about workload distribution, timing calculations, or performance targets.
In those scenarios, assuming the CPU can sustain 7.3 GHz when the real ceiling is 5.7 GHz leads to miscalculated timers, incorrectly throttled workloads, and misbehaving real-time applications. In embedded and edge deployments, where timing accuracy matters more than on a general desktop, that is not a theoretical concern.
The patch series submitted to address the problem corrects the scaling factor table entry for Bartlett Lake’s CPU model identifier. Once merged, the kernel will calculate and report the correct maximum frequency based on the hardware’s actual capabilities.
No user action is needed after the fix lands. The corrected value will appear automatically following a kernel update.
What makes this story worth paying attention to is the broader signal it sends. Bartlett Lake has been shipping in production hardware, running Linux, with a frequency reporting bug that nobody at Intel caught before external developers hit it in real deployments.
For a platform that Intel is positioning specifically at Linux-heavy embedded and edge markets, that gap in pre-release kernel validation is a notable oversight.
The patch is currently under review on the Linux kernel mailing list at the Lore Kernel page. If it clears review without objections, it is a candidate for inclusion in an upcoming stable kernel point release or the Linux 7.1 development cycle.
