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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5114de6a-e6ef-4459-9570-6dd2245fabd5@yahoo.fr>
Date: Tue, 25 Feb 2025 09:11:26 +0100
From: Fab Stz <fabstz-it@...oo.fr>
To: Thomas Gleixner <tglx@...utronix.de>, 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

Hello Thomas,

Thank you for the patch! I built the 6.1 kernel with it applied and it 
apparently works as expected (no delay). Please find logs below & 
attached dmesg log. Maybe the interesting line is:

Feb 25 08:53:51 debian kernel: tsc: Marking TSC unstable due to TSC 
halts in idle

Comparison shows that it is "Marking TSC unstable due to boot parameter" 
with a non patched kernel + tsc=unstable.

+ cat /sys/devices/system/cpu/cpuidle/available_governors
ladder menu
+ cat /sys/devices/system/cpu/cpuidle/current_driver
intel_idle
+ cat /sys/devices/system/cpu/cpuidle/current_governor
menu
+ cat /sys/devices/system/cpu/cpuidle/current_governor_ro
menu
+ ls /sys/devices/system/cpu/cpu0/cpuidle/
state0  state1  state2  state3
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
POLL
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state0/disable
0
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state1/name
C1_ACPI
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
0
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state2/name
C2_ACPI
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state2/disable
0
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state3/name
C3_ACPI
+ cat /sys/devices/system/cpu/cpu0/cpuidle/state3/disable
0


Will the patch also enter the longterm releases like 6.1?

Regards
Fab


Le 24/02/2025 à 09:13, Thomas Gleixner a écrit :
>>>> 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;
>   	}


View attachment "patched.log" of type "text/x-log" (2020 bytes)