Linux 5.15-rc5 x86 Changes Aim To Fix "Yet Another Hardware Trainwreck"

Sent in this morning were an urgent set of x86 updates for the Linux 5.15-rc5 kernel due out later today.

With this x86/urgent pull request is "Yet another attempt at fixing the never-ending saga of botched x86 timers, this time because some incredibly smart hardware decides to turn off the HPET timer in a low power state - who cares if the OS is relying on it..."

The patch by longtime kernel developer Thomas Gleixner is to "use another crystalball to evaluate HPET usability." He describes the problem of HPET (high precision event timer) stopping on modern Intel systems when hitting the PC10 idle state. HPET stopping at that low-power state happens even if the OS/kernel is utilizing it.

Previously there were quirks in the kernel trying to workaround the HPET problem but now HPET usage will be force-disabled on PC10 presence instead. Gleixner calls this "yet another hardware trainwreck" with the patch. This started back in 2019 when Linux began disabling HPET on select Intel platforms over problems with those PCI ID based quirks for determining to force disable HPET but given the broadening of the issue it's going to just disable it when PC10 is present.

There also is a new comment with the patch code:

HPET is a piece of hardware designed by committee and the only reasons why it is still in use on modern systems is the fact that it is impossible to reliably query the TSC frequency via CPUID or firmware.

If HPET is functional it is useful for calibrating TSC, but this can be done via PMTIMER as well which seems to be the last remaining timer on X86/INTEL platforms that has not been completely wreckaged by feature creep.

In theory HPET support should be removed altogether, but there are older systems out there which depend on it because TSC and APIC timer are dysfunctional in deeper C-states.

It's only 20 years now that hardware people have been asked to provide reliable and discoverable facilities which can be used for timekeeping and per CPU timer interrupts.

The probability that this problem is going to be solved in the forseeable future is close to zero, so the kernel has to be cluttered with heuristics to keep up with the ever growing amount of hardware and firmware trainwrecks. Hopefully some day hardware people will understand that the approach of "This can be fixed in software" is not sustainable. Hope dies last...

That is what is most prominent with today's x86/urgent pull for Linux 5.15.