From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5EB6E33689F for ; Tue, 3 Mar 2026 21:56:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772574991; cv=none; b=gHZAFPl4WNFky9R0tN4yAjeIAcgEt4W0z7C2QSyZyWnyLFIvZ6InXuMTMkVkqvzV8httgeJDyPX1J1SVIR18/CVOSdzc48icZRrC7o3Rx+C3QQj2x+PF6NDpVa9P7ogc1B6EgpFLMcTqIr5wpoMzk9Obs2HG/7hwEbumxjls5SY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772574991; c=relaxed/simple; bh=K1/iwvfVvhGhesVtqzgfcMwY1CbUB98RUVRDCs+HJ9k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=tVU8Ppui+TcZIKYWMYNGRABUewyfCfNWuixazd0lyJ5omPcv03Q00lS+V9SOrbuAbvK5fxUd4RTSed7UIJ9tQoJGAR/vcWLB8byGmv3mhotzVFYTOGXr9mSwdQYRbsJrsYrhL9YJ3+4HNI8lIR3xgfG9rILC7W+5sVDccxxEi/M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bfjjqw0F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bfjjqw0F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78FFFC116C6; Tue, 3 Mar 2026 21:56:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772574991; bh=K1/iwvfVvhGhesVtqzgfcMwY1CbUB98RUVRDCs+HJ9k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bfjjqw0FrOgOJ9XOEycSQpaFf0Vf2wqu//lSc/msJ19mIm/OaSNHuJ3m6GfWIfsAO +ZmIULkn3SCUDKZA/t5JB5oORT4UMgkZ4qm38UD7NdeQ8gdCZAnrHmOjSBA9o9l7Ly I/7hUNoJBKaAfbF6MKiRKDeCje3s+73cpzY1FWFEfcxfy31GqOFdyIEj/ypmIO0+Mm ZmThl3L0KPwtU8Yx7DUzDrB7nwmqGAq38Pfq2ahoapml9DQ54wvE++Ecz6tjTueJz/ rdo3R+FvemtNTmSdM3++c6Z3X56/LLcTqLAyMB//ue5ZICr+rzqAzXRY+NMhuLfMXW L+yB9eR7kvW7Q== From: Thomas Gleixner To: Nathan Chancellor Cc: LKML , Anna-Maria Behnsen , John Stultz , Stephen Boyd , Daniel Lezcano , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , x86@kernel.org, Peter Zijlstra , Frederic Weisbecker , Eric Dumazet Subject: [PATCH] Subject: timekeeping: Initialize the coupled clocksource conversion completely In-Reply-To: <20260303173809.GA1114907@ax162> References: <20260224163022.795809588@kernel.org> <20260224163430.076565985@kernel.org> <20260303012905.GA978396@ax162> <87jyvtyo6o.ffs@tglx> <20260303173809.GA1114907@ax162> Date: Tue, 03 Mar 2026 22:56:27 +0100 Message-ID: <87bjh4zies.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 Nathan reported a boot failure after the coupled clocksource/event support was enabled for the TSC deadline timer. It turns out that on the affected test systems the TSC frequency is not refined against HPET, so it is registered with the same frequency as the TSC-early clocksource. As a consequence the update function which checks for a change of the shift/mult pair of the clocksource fails to compute the conversion limit, which is zero initialized. This check is there to avoid pointless computations on every timekeeping update cycle (tick). So the actual clockevent conversion function limits the delta expiry to zero, which means the timer is always programmed to expire in the past. This obviously results in a spectacular timer interrupt storm, which goes unnoticed because the per CPU interrupts on x86 are not exposed to the runaway detection mechanism and the NMI watchdog is not yet functional. So the machine simply stops booting. That did not show up in testing. All test machines refine the TSC frequency so TSC has a differrent shift/mult pair than TSC-early and the conversion limit is properly initialized. Cure that by setting the conversion limit right at the point where the new clocksource is installed. Fixes: cd38bdb8e696 ("timekeeping: Provide infrastructure for coupled clockevents") Reported-by: Nathan Chancellor Signed-off-by: Thomas Gleixner Tested-by: Nathan Chancellor Closes: https://lore.kernel.org/20260303012905.GA978396@ax162 --- kernel/time/timekeeping.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -404,6 +404,13 @@ static void tk_setup_internals(struct ti */ clocks_calc_mult_shift(&tk->cs_ns_to_cyc_mult, &tk->cs_ns_to_cyc_shift, NSEC_PER_MSEC, clock->freq_khz, 3600 * 1000); + /* + * Initialize the conversion limit as the previous clocksource + * might have the same shift/mult pair so the quick check in + * tk_update_ns_to_cyc() fails to update it after a clocksource + * change leaving it effectivly zero. + */ + tk->cs_ns_to_cyc_maxns = div_u64(clock->mask, tk->cs_ns_to_cyc_mult); } }