Re: [PATCH v7 3/7] timekeeping: Account for clocksource tick quantisation via NTP

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2026-07-09 at 14:56 +0200, Marek Szyprowski wrote:
> 
> This patch landed yesterday in linux-next as commit e8bf3955dc2f
> ("timekeeping: Account for clocksource tick quantisation via NTP").
> In my tests I found that it breaks booting Raspberry Pi 3B and Pi 4B
> boards in ARM 32bit mode with quite old (Debian 10) userspace. Booting
> freezes just before getting a getty login prompt and no more kernel
> or userspace messages are observed. If I start with init=/bin/bash in
> kernel cmdline and then wait a while and do "exec /sbin/init" I get
> the following additional kernel message:
> 
> [  186.867605] Adjusting arch_sys_counter more than 11% (12136 vs 344864995)
> 
> then booting freezes again before getting getty prompt.
> 
> I can do some more tests, just let me know what will help debugging this
> issue. Other ARM 32bit machines I have work fine with this patch.
> 
> Reverting subject together with its dependencies on top of linux-next 
> fixes the issue.

Thank you.

I'm confused at this, because it's basically adding the *same* delta to
the tick, just in a different place.

While I go and frown at the maths a bit more... would you mind testing
if *just* the change from TK_CLOCK_WAS_SET to TK_UPDATE_ALL in
timekeeping_init() is the culprit?

Could you add some pr_info() of xtime_remainder and cs_tick_adj (in the
before vs. after cases)?