linux-kernel - Re: [REGRESSION] ? system is stuck in clocksource, >60s delay at boot time without tsc=unstable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <874j0jhiag.ffs@tglx>
Date: Mon, 24 Feb 2025 09:13:27 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Fab Stz <fabstz-it@...oo.fr>, John Stultz <jstultz@...gle.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>, Anna-Maria Behnsen
 <anna-maria@...utronix.de>, Frederic Weisbecker <frederic@...nel.org>,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, Jacob Pan
 <jacob.jun.pan@...ux.intel.com>, Len Brown <lenb@...nel.org>, "Rafael J.
 Wysocki" <rafael@...nel.org>
Subject: Re: [REGRESSION] ? system is stuck in clocksource, >60s delay at
 boot time without tsc=unstable

Fab!

On Sun, Feb 23 2025 at 18:01, Fab Stz wrote:
> Le 15/01/2025 à 17:59, Thomas Gleixner a écrit :
>> AFAICT, that iMac 9.1 is Core 2 Duo based and that generation of
>> processors definitely had issues with the TSC in deeper idle states.
>
> Indeed, cpuinfo reports:
>
> model name      : Intel(R) Core(TM)2 Duo CPU     E8135  @ 2.66GHz

Ok.

>>> BTW, I tried the "processor.max_cstate=1" you mentioned but it didn't
>>> change anything on the delay and/or warning.
>> 
>> That's weird, but we have no idea what kind of magic the BIOS implements
>> there for power management behind the kernels back. I assume that it
>> does because this generation of CPUs uses the ACPI processor idle driver
>> and that disables TSC when it detects that the system supports
>> C-states > 1.
>
> Output of these commands can be found in attached file cpuidle.txt

> + cat /sys/devices/system/cpu/cpuidle/current_driver
> intel_idle

So according to that the intel_idle driver is in use, which does not
have the magic TSC workarounds like the acpi processor driver has, but
it seems to be loaded preferred.

Sigh. Why is the intel_idle driver so agressive in taking over despite
the fact that it does not handle the old CPUs, which are known to
require the TSC workaround? It handles the APIC stops in C2, but not the
TSC oddity while the original ACPI processor_idle driver does the right
thing for more than two decades....

> Can the kernel be patched so that the proper config is used 
> automatically (ie. without the user having to set any parameter)? I'm 
> not sure my question actually makes sense.

Yes, we can. Untested patch below. It just brings the intel idle driver
on par with the original ACPI processor idle driver to deal with that
problem.

Thanks,

        tglx
---
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 118fe1d37c22..0fdb1d1316c4 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -56,6 +56,7 @@
 #include <asm/intel-family.h>
 #include <asm/mwait.h>
 #include <asm/spec-ctrl.h>
+#include <asm/tsc.h>
 #include <asm/fpu/api.h>

 #define INTEL_IDLE_VERSION "0.5.1"
@@ -1799,6 +1800,9 @@ static void __init intel_idle_init_cstates_acpi(struct cpuidle_driver *drv)
 		if (intel_idle_state_needs_timer_stop(state))
 			state->flags |= CPUIDLE_FLAG_TIMER_STOP;

+		if (cx->type > ACPI_STATE_C1 && !boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
+			mark_tsc_unstable("TSC halts in idle");
+
 		state->enter = intel_idle;
 		state->enter_s2idle = intel_idle_s2idle;
 	}