The Linux Kernel built its reputation, in part, on its efficiency on older machines that do not support modern operating systems like Windows 11. However, maintaining such extreme backward compatibility comes at a significant technical cost. The recent decision to mandate the TSC (Time Stamp Counter) on x86 processors demonstrates that maintainers have prioritized engineering evolution over the past. In practice, this means Linux has set aside nostalgia to focus on the technological performance of the future.
The latest version of the Linux Kernel (7.2, released on August 16, 2026) made the TSC a mandatory requirement for x86 processors, putting an end to decades of compatibility code that allowed the operating system to run on hardware lacking reliable TSC support. The technical change, implemented under the title "x86/cpu: Make CONFIG_X86_TSC unconditional," removes the configuration logic that previously allowed the kernel to be compiled without TSC support.
This change directly affects home users with very old machines (dating from before approximately 1993) because, starting with Linux Kernel 7.2, if you attempt to load the system on an x86 processor that lacks the TSC register, the kernel will refuse to boot, and the system will not start. This signals a significant shift in the Linux kernel's development philosophy, yet it is not the Linux equivalent of Windows 11's TPM 2.0 requirement. The TSC has been present in x86 processors since the launch of the Intel Pentium in 1993. If your processor was manufactured within the last three decades, it almost certainly includes it. The change actually aims to permanently remove compatibility code for hardware that is unlikely to run a modern Linux kernel. However, modern processors from the 1990s or later should not exhibit timing issues related to a lack of TSC support, although the kernel might refuse to boot on very old x86 CPUs that lack the TSC register.
Windows, macOS, and FreeBSD have long relied on the TSC, but their approach differs from how Linux handled it in kernel version 7.2. Windows, for instance, does not prevent the computer from booting if the processor lacks a TSC; instead, it makes that determination at runtime. If the TSC on a very old processor fails or proves unstable, Windows automatically switches to motherboard-based timers (such as HPET or the ACPI PM Timer). Of course, attempting to install Windows 11 on an older machine results in the installation failing outright, but this is due to other factors—such as TPM 2.0, Secure Boot, and processor generation (Microsoft limits official support to 8th-generation Intel processors—released in 2017—or AMD Ryzen 2000 series and newer).
What is TSC?
The TSC is a 64-bit internal physical register found within each x86 CPU core (each core has its own TSC register). It provides a basic clock-cycle counting feature, offering the precision essential for smooth operating system operation; it delivers high-resolution timing and can be read much faster than platform alternatives like HPET or the ACPI PM timer. Reading a TSC-based timer might take tens to hundreds of CPU cycles, whereas accessing a motherboard-based timer can take approximately 0.8 to 1.0 microseconds.
Having an individual TSC for each core caused issues: if a core changed its clock speed to save power, its TSC would count more slowly than that of a neighboring core (leading to time desynchronization in Linux). This is why modern CPUs feature "Constant TSC," which ensures all these internal registers run at the same speed regardless of power usage.
The TSC has three basic operational characteristics:
- Cycle Counter: Its sole function is counting. For every clock cycle the processor executes, the register increments by 1.
- Initialization: It starts at 0 the moment the processor receives power (hardware reset) and increments continuously.
- Direct Reading: To read the register's value, programmers and the kernel use a specific assembly instruction called RDTSC (Read Time-Stamp Counter).
Historically, Linux maintained code to handle processors lacking a reliable TSC, dating back to the i486 era. The Linux 7.0 kernel dropped support for Intel 486 processors, and subsequent development cycles removed additional legacy hardware that had prevented the TSC from being treated as universal. Essentially, hardware predating the Pentium or from the i486 era will be affected. For decades, Linux maintained complex "fallback" routines to support timers based on older motherboards. Eliminating this dead code simplifies kernel maintenance. This is a case of technical debt—specifically, unnecessary maintenance consuming hours of highly skilled labor to support a statistically insignificant segment of users. Unlike Microsoft's controversial hardware requirements (such as TPM 2.0 for Windows 11), the TSC requirement for Linux 7.2 is simply a matter of engineering housekeeping regarding "museum pieces."
Checking TSC support and stability
To check if your computer supports TSC, run:
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
The output should be `tsc`.
Verify this by checking the file of available sources:
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
The output should look something like this: tsc hpet acpi_pm
If "tsc" is missing from this list, it means the operating system has completely lost access to it.
For the TSC to be considered modern and perfectly stable, the CPU must possess two physical properties:
- Constant TSC: The counter advances at a constant rate, even if the CPU changes frequency (turbo mode or power-saving mode).
- Nonstop TSC: The counter does not stop running, even if the CPU core enters a deep sleep state (C-states).
You can check if your CPU has these features using the following command:
$ lscpu | grep -E "constant_tsc|nonstop_tsc"
Options: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi
Or by directly inspecting the processor flags:
$ cat /proc/cpuinfo | grep -E "constant_tsc|nonstop_tsc" | uniq
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb pti tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi
You can check if the kernel encountered any synchronization issues between CPU cores during boot:
$ sudo dmesg | grep -i tsc
[ 0.000000] tsc: Detected 3399.906 MHz TSC
[ 0.036386] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x52 (or later)
[ 0.120153] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x3101f59f5e6, max_idle_ns: 440795259996 ns
[ 2.251217] clocksource: Switched to clocksource tsc-early
[ 3.281461] tsc: Refined TSC clocksource calibration: 3407.999 MHz
[ 3.281465] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fd336761, max_idle_ns: 440795243819 ns
[ 3.281476] clocksource: Switched to clocksource tsc
[ 4.246774] vboxdrv: TSC mode is Invariant, tentative frequency 3407999019 Hz
- clocksource: Switched to clocksource tsc: Your Linux kernel has tested, validated, and enabled the TSC as the system's primary time source. It is operational.
- Refined TSC clocksource calibration: 3407.999 MHz: The kernel has calibrated your TSC frequency with high precision to approximately 3.4 GHz.
- vboxdrv: TSC mode is Invariant: The VirtualBox driver has confirmed that your TSC is of the "Invariant" type—equivalent to the "Constant/Nonstop" type mentioned earlier. This means its speed does not change, making it safe for running virtual machines.
