Linux Kernel Misreports Intel Bartlett Lake CPU Clock Speeds

Intel's recently launched Bartlett Lake P-core processors, designed specifically for the embedded market, are facing an unexpected issue under Linux: the kernel's Intel P-State driver is reporting maximum clock speeds of 7.0+ GHz when these CPUs can only boost up to 5.7GHz in reality. This significant discrepancy has been identified by QNAP engineer Henry Tseng, who has developed a patch series to correct the CPU scaling factor for these processors.

The Technical Details

The issue centers on the Intel P-State CPU frequency scaling driver in the Linux kernel. For Bartlett Lake P-core-only SKUs like the Intel Core 9 273PE, the cpuinfo_max_freq is being reported as 7.0/7.3 GHz, which exceeds the datasheet specification for the Max Turbo Frequency of 5.7 GHz. This misreporting occurs due to an incorrect CPU scaling factor being propagated for these processors.

The fix, as described by Tseng, is remarkably concise—a six-line patch to the Intel P-State driver that corrects the scaling factor. This simple change ensures that the kernel reports the accurate maximum frequencies for these P-core-only processors.

Benchmarks and Performance Implications

While this misreporting doesn't affect the actual performance of the CPUs, it creates confusion for system administrators and enthusiasts who rely on accurate frequency information for:

• Performance monitoring and benchmarking
• Power consumption calculations
• Thermal management decisions
• System stability assessments

For those running benchmarks on Bartlett Lake systems, the incorrect frequency reporting could lead to misinterpretation of results. If a benchmark tool queries the system for maximum clock speed and receives 7.3GHz as the answer, it might expect performance levels that the CPU cannot actually achieve.

Build Recommendations for Bartlett Lake Systems

For those deploying Bartlett Lake processors in Linux environments:

1. Apply the upcoming patch: Monitor the Linux kernel mailing list and QNAP's contributions for the official patch to be merged.
2. Verify actual performance: Use benchmarking tools that measure actual performance rather than relying solely on reported clock speeds.
3. Monitor thermals: Given the embedded nature of these CPUs, proper cooling is essential to maintain sustained performance.
4. Consider alternative monitoring tools: Tools like cpupower or lm-sensors can provide more accurate system information during the transition period.

Why This Matters for Embedded Computing

Bartlett Lake processors are designed for embedded and edge computing applications where Linux is the dominant operating system. These environments often require precise system information for:

• Real-time performance guarantees
• Power efficiency calculations
• Thermal management in constrained environments
• Long-term stability monitoring

The fact that this issue was discovered only after the CPUs began shipping to customers is surprising, especially given the heavy reliance on Linux in the embedded space. More notably, it's a QNAP engineer rather than Intel engineers who has taken the initiative to address this Linux-specific driver issue.

The Patch Details

According to the information shared by Henry Tseng, the fix involves correcting the CPU scaling factor in the Intel P-State driver. While the exact implementation details are still being finalized, the approach is straightforward:

1. Identify the correct scaling factor for Bartlett Lake P-core processors
2. Update the driver to use this factor instead of the current incorrect value
3. Ensure the change doesn't affect other processor families

This type of fix is common in Linux kernel development, where community members and engineers from various companies contribute improvements to drivers and subsystems.

Looking Forward

As Intel continues to develop processors for embedded and edge computing, maintaining accurate Linux support becomes increasingly important. This incident highlights the collaborative nature of Linux kernel development, where companies like QNAP contribute fixes for issues that affect their specific use cases.

For those interested in following the progress of this fix, monitoring the Linux kernel mailing lists and QNAP's contributions would be advisable. The patch is expected to be merged in upcoming kernel releases, resolving the frequency reporting discrepancy for Bartlett Lake processors.

This situation serves as a reminder that even in the mature world of Linux kernel development, occasional oversights can occur, particularly with new processor families. The community-driven nature of Linux development ensures that such issues are typically identified and addressed relatively quickly, as demonstrated by this case.