Linux 5.15-rc5 x86 changes aim to fix “yet another hardware train crash”

0


[ad_1]

An urgent set of x86 updates for the 5.15-rc5 Linux kernel was sent this morning.

With this x86 / urgent mining request is “Yet another attempt to fix the endless saga of sloppy x86 timers, this time because some incredibly smart hardware decides to shut down the HPET timer in a low power state – which cares if the operating system is relying on it … ”

Longtime kernel developer Thomas Gleixner’s fix is ​​to “use another crystal ball to assess the usability of HPET.” It describes the issue of HPET (High Precision Event Timer) shutting down on modern Intel systems when it reaches the idle state of PC10. HPET shutdown at this low power state occurs even if the operating system / kernel is using it.

Previously there were quirks in the kernel trying to work around the HPET issue, but now the use of HPET will be forcibly disabled on the presence of PC10 instead. Gleixner calls this “yet another material wreck” with the patch. It started in 2019 when Linux started disabling HPET on some Intel platforms due to issues with these PCI ID based quirks to determine to force HPET to be disabled, but given the widening issue, it will simply deactivate it when PC10 is present.

There is also a new comment with the patch code:

HPET is committee-designed hardware and the only reasons it is still used on modern systems is the fact that it is impossible to reliably poll the TSC frequency via CPUID or firmware.

If HPET is functional, it is useful for calibrating TSC, but this can also be done via PMTIMER, which appears to be the last remaining timer on X86 / INTEL platforms which has not been completely destroyed by the feature slippage.

In theory, HPET support should be removed completely, but there are older systems that depend on it because TSC and APIC timers are dysfunctional in deeper C states.

It has only been 20 years now that hardware specialists have been asked to provide reliable and discoverable facilities that can be used for timing and through CPU timer interrupts.

The probability that this problem will be fixed in the foreseeable future is close to zero, so the kernel must be cluttered with heuristics to cope with the ever increasing amount of hardware and firmware failures. Hopefully one day the hardware folks will understand that the “It can be fixed in software†approach is not viable. Hope dies last …

This is what is most important with today’s x86 / urgent pull for Linux 5.15.

[ad_2]

Share.

Leave A Reply