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: <15f4f44d-6f73-4031-a7dc-d2105672bc81@yahoo.fr>
Date: Sun, 23 Feb 2025 18:01:12 +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
Subject: Re: [REGRESSION] ? system is stuck in clocksource, >60s delay at boot
 time without tsc=unstable

Dear Thomas,

I eventually could proceed with the suggested checks. See below.

Le 15/01/2025 à 17:59, Thomas Gleixner a écrit :
>> Maybe the USB drivers somehow rely on a reliable clock source for
>> proper functioning.
> 
> The kernel relies on a reliable clocksource. Loading the USB driver merely
> exposes the problem because it probably causes a long enough delay to
> get the CPUs into a state which exposes the issue.
> 
> 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

>> 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.
> 
> # cat /sys/devices/system/cpu/cpuidle/
> 
> tells which idle driver is actually in use.
> 
> # ls /sys/devices/system/cpu/cpu0/cpuidle/
> 
> tells which states are supported by the driver

> # cat /sys/devices/system/cpu/cpu0/cpuidle/state$N/name
> # cat /sys/devices/system/cpu/cpu0/cpuidle/state$N/disable

> tells the actual C-state name and the disabled state, but I expect that
> there is nothing to see.

Output of these commands can be found in attached file cpuidle.txt

> Can you try 'idle=halt' instead?

When using idle=halt (without tsc=unstable) I haven't encountered the delay.

Extract of the kernel log can be found in attached file 
kernel_log_idle=halt.txt I also attach it for when using tsc=unstable & 
wihtout any of these two.

So, which parameter is most suitable for this CPU/system?

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.

Thank you, & regards.
Fab

View attachment "cpuidle.txt" of type "text/plain" (3346 bytes)

View attachment " kernel_log_idle=halt.txt " of type "text/plain" (1554 bytes)

View attachment " kernel_log_tsc=unstable.txt " of type "text/plain" (1262 bytes)

View attachment " kernel_log_noParam.txt " of type "text/plain" (2657 bytes)