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

[Arnd Bergmann]

On Thu, Jul 9, 2026, at 14:56, Marek Szyprowski wrote:
> On 21.06.2026 23:53, David Woodhouse 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.

Hi Marek,

Are you running a 32-bit or 64-bit kernel with your 32-bit 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.

IIRC, there are some variants of these machines with broken
arch timer. Can you check on the working kernel whether
the vdso clock_gettime64 helper is enabled, and whether the
"arm,cpu-registers-not-fw-configured" property is set on
the arm,armv7-timer node?

If it's not that, the difference between the working and
non-working systems could be the clock frequency behind
the arch timer, which differs wildly between systems,
you should see a "cp15 timer running at ... MHz" message
that tells you what is is 

      Arnd