From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A660D19E997 for ; Wed, 15 Jan 2025 16:59:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736960355; cv=none; b=eQdoNFDRNA3mTSfnyDE393/oYXJvFlHNj6Xrpg67C+pXzeTJug13lb6Qswpg8O0V8S1HQv25hAFk/QggvxgWW5J9Qd4GAov/nw4VLG4M6wqZBttcSXEaMqdWzeFUKBQoaeS8f7beAoPV5MTQQNl3ivDZYlfo7R5MfOrGX0npQzE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736960355; c=relaxed/simple; bh=nte0Z9wSyN7xqDXM7JnTh8E0rFoJaLSM1rOQPfqdHRw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=X9+lPJaaBnCirsyYF4WMHggk8uMiMw7SiJv9rm0eEJHc6FieOJSWVoSSkQXLgXtm4dDIxAwvK4Vr80kwNKLBmdkiCxX5siSO8ogTRMfeIHwm65UDVTvc0gGNlZ3MFgLQq3TFNSZUV6lE3USA281gXp4W00riUoiwK0NMa85ueaQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=VV01LSTf; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=PXByaVXW; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="VV01LSTf"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="PXByaVXW" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1736960351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UU0HYOAIOF+M0SFV4YJBYNNW1ONH4p1jmrF89Xk0Ipc=; b=VV01LSTfwXhwWTc8HFjDm7zvN2+SLUTnud3usAKE1n0+KtfQU/CH9oOGu/FepExoTu6Gcy HYzJ6T79ZSkOr7uSD63ZimteipBTcxLmycvrVOB2tdiCcTIn90hstspWW/INJjBJ+wqkIK 9T7MkyoyGwq92E47ui3sWdY7M/qJRwITxFTZUWd2FOvBOwJ31PM4YxtV2r705MRWhVPqdn 0Ys9LhjEoBxkNMcefbcFG26ZGAh9n17w81LXuPeg0sUhdD+KCbGK3fmmit1W8zWM2UD06e XixF8vcAC1B/7BXyyJss5HnJhlmyNMxrpmGsRl+8sxdqNqhYHS3rH+rJWsDqNg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1736960351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UU0HYOAIOF+M0SFV4YJBYNNW1ONH4p1jmrF89Xk0Ipc=; b=PXByaVXWZ9jh6qM1aQ4+xpIWwWAGmfeQ6gShG4t0Zywv9S9kUSVTVf2nLDbMX4jDj6AnK2 zkogLyL7sJHtn1CQ== To: Fab Stz , John Stultz Cc: Daniel Lezcano , Anna-Maria Behnsen , Frederic Weisbecker , linux-kernel@vger.kernel.org Subject: Re: [REGRESSION] ? system is stuck in clocksource, >60s delay at boot time without tsc=unstable In-Reply-To: References: <10cf96aa-1276-4bd4-8966-c890377030c3.ref@yahoo.fr> <10cf96aa-1276-4bd4-8966-c890377030c3@yahoo.fr> <22539099.EfDdHjke4D@debian> Date: Wed, 15 Jan 2025 17:59:11 +0100 Message-ID: <87plkoau8w.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Jan 04 2025 at 23:02, Fab Stz wrote: > Le 03/01/2025 =C3=A0 20:02, John Stultz a =C3=A9crit : > When building the kernel from the sources from the stable repo of the=20 > kernel to try a git bisect I couldn't reproduce a case where the warning= =20 > is before loading '/init' with the versions I mentioned as working.=20 > Maybe I was just lucky as you mentioned. If the warning comes before the= =20 > loading of USB modules, there is no delay. If it comes after, there is a= =20 > delay. This is a timing problem, which depends on kernel configuration and run-time differences, but that's just a symptom. It explains why you are seeing it sometimes and sometimes not. Nothing else. > If I break/pause at the beginning of the /init script, the warning never= =20 > comes before. I don't really understand what is happening and where the=20 > problem actually lies (kernel? systemd? udev? somewhere else?). If I add= =20 > a "sleep 5" as 1st command in "/init" it would take ages. So as long as=20 > the warning from the clocksource is not displayed, the delays seem=20 > completely wrong. That's an interesting data point because that 'sleep 5' puts the system into idle and probably into deep idle for the first time during boot. > 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. > BTW, I tried the "processor.max_cstate=3D1" you mentioned but it didn't=20 > 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. Can you try 'idle=3Dhalt' instead? Thanks, tglx