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

[Marek Szyprowski]

On 09.07.2026 15:19, Arnd Bergmann wrote:
> 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.
> Are you running a 32-bit or 64-bit kernel with your 32-bit userspace?

32bit kernel and 32bit 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?

It is not set. I use vanilla dtb from mainline.


> 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 

I use multi_v7_defconfig from arch/arm, it has CONFIG_VDSO=y.

Relevant lines from kernel log (RPi4 board, $subject patch reverted):

[    0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.000001] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.008453] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.017911] bcm2835: system timer (irq = 25)
[    0.025858] arch_timer: cp15 timer running at 54.00MHz (sec-phys).
[    0.032113] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[    0.043023] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[    0.051121] Switching to timer-based delay loop, resolution 18ns

root@target:~# grep -a "" /sys/firmware/devicetree/base/timer/compatible
arm,armv8-timer
root@target:~# ls -la /sys/firmware/devicetree/base/timer/
total 0
drwxr-xr-x  2 root root  0 Jan  1 00:00 .
drwxr-xr-x 27 root root  0 Jan  1 00:00 ..
-r--r--r--  1 root root 16 Jan  1 00:00 compatible
-r--r--r--  1 root root 48 Jan  1 00:00 interrupts
-r--r--r--  1 root root  6 Jan  1 00:00 name

With CONFIG_VDSO disabled same issue happens.

Adding "arm,cpu-registers-not-fw-configured" property to arch_timer
doesn't change anything.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland