Re: [PATCH] Subject: timekeeping: Initialize the coupled clocksource conversion completely

[John Stultz]

On Tue, Mar 3, 2026 at 1:56 PM Thomas Gleixner <tglx@xxxxxxxxxx> wrote:
>
> 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 <nathan@xxxxxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxx>
> Tested-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> Closes: https://lore.kernel.org/20260303012905.GA978396@ax162

Acked-by: John Stultz <jstultz@xxxxxxxxxx>

thanks
-john