On Tue, Jun 16, 2026 at 08:47:00PM +0200, Marek Szyprowski wrote: > Dear All, > > On 13.06.2026 15:28, tip-bot2 for Thomas Gleixner wrote: > > The following commit has been merged into the timers/core branch of tip: > > > > Commit-ID: f24df84cbe05e4471c04ac4b921fc0340bbc7752 > > Gitweb: https://git.kernel.org/tip/f24df84cbe05e4471c04ac4b921fc0340bbc7752 > > Author: Thomas Gleixner > > AuthorDate: Tue, 09 Jun 2026 17:14:45 +02:00 > > Committer: Thomas Gleixner > > CommitterDate: Sat, 13 Jun 2026 15:22:40 +02:00 > > > > time/jiffies: Register jiffies clocksource before usage > > > > Teddy reported that a XEN HVM has a long boot delay, which was bisected to > > the recent enhancements to the negative motion detection. It turned out > > that the jiffies clocksource is used in early boot before it is registered, > > which leaves the max_delta_raw field at zero. That causes the read out to > > be clamped to the max delta of 0, which means time is not making progress. > > > > Cure it by ensuring that it is initialized before its first usage in > > timekeeping_init(). > > > > Fixes: 76031d9536a0 ("clocksource: Make negative motion detection more robust") > > Reported-by: Teddy Astie > > Signed-off-by: Thomas Gleixner > > Tested-by: Teddy Astie > > Cc: stable@vger.kernel.org > > Link: https://patch.msgid.link/87y0gn3fve.ffs@fw13 > > Closes: https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech > This patch landed recently in linux-next as commit f24df84cbe05 ("time/jiffies: > Register jiffies clocksource before usage"). In my tests I found that it triggers > the following warning on Qualcomm Robotics RB5 board > (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts): > > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns > > ============================= > [ BUG: Invalid wait context ] > 7.1.0-rc1+ #16790 Not tainted > ----------------------------- > swapper/0/0 is trying to lock: > ffffb0d1364d1270 (clocksource_mutex){....}-{4:4}, at: __clocksource_register_scale+0x204/0x3e8 > other info that might help us debug this: > context-{5:5} > 1 lock held by swapper/0/0: >  #0: ffffb0d1376855f0 (&tkd->lock){....}-{2:2}, at: timekeeping_init+0x13c/0x21c > stack backtrace: > CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.1.0-rc1+ #16790 PREEMPT > Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) > Call trace: >  show_stack+0x18/0x24 (C) >  dump_stack_lvl+0x90/0xd0 >  dump_stack+0x18/0x24 >  __lock_acquire+0xa48/0x225c >  lock_acquire+0x1c4/0x3f0 >  __mutex_lock+0xa8/0x8e4 >  mutex_lock_nested+0x24/0x30 >  __clocksource_register_scale+0x204/0x3e8 >  clocksource_default_clock+0x48/0x64 >  timekeeping_init+0x148/0x21c >  start_kernel+0x4c8/0x8dc >  __primary_switched+0x88/0x90 > arch_timer: cp15 timer running at 19.20MHz (virt). > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns > > > Reverting $subject on top of linux-next fixes this issue. Same here: 0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.000000] [ 0.000000] ============================= [ 0.000000] [ BUG: Invalid wait context ] [ 0.000000] 7.1.0-06889-g4b99990cdf95 #1 Tainted: G W [ 0.000000] ----------------------------- [ 0.000000] swapper/0/0 is trying to lock: [ 0.000000] ffffffff820cd258 (clocksource_mutex){....}-{4:4}, at: __clocksource_register_scale+0x222/0x306 [ 0.000000] other info that might help us debug this: [ 0.000000] context-{5:5} [ 0.000000] 1 lock held by swapper/0/0: [ 0.000000] #0: ffffffff82fdae70 (&tkd->lock){....}-{2:2}, at: timekeeping_init+0x1a4/0x25e [ 0.000000] stack backtrace: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G W 7.1.0-06889-g4b99990cdf95 #1 PREEMPT_RT [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) [ 0.000000] Call Trace: [ 0.000000] [] dump_backtrace+0x1c/0x24 [ 0.000000] [] show_stack+0x28/0x34 [ 0.000000] [] dump_stack_lvl+0x60/0x88 [ 0.000000] [] dump_stack+0x14/0x1c [ 0.000000] [] __lock_acquire+0x81c/0x234e [ 0.000000] [] lock_acquire+0x2e0/0x460 [ 0.000000] [] mutex_lock_nested+0x44/0x8a [ 0.000000] [] __clocksource_register_scale+0x222/0x306 [ 0.000000] [] clocksource_default_clock+0x48/0x62 [ 0.000000] [] timekeeping_init+0x1b6/0x25e [ 0.000000] [] start_kernel+0x67c/0xc66 [ 0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns In your case, do you also see an increase in logging verbosity, as if you had enabled debug on your commandline? Cheers, Conor.