Long boot time with Xen HVM guests during PV spinlock initialization

REGRESSION Applied Teddy Astie 6 participants 12 messages Jun 8 – Jun 17

Subsystems (2)

Stable branch Regressions

lore

Share & tools

lore

Teddy Astie

author

2026-06-08 10:30 UTC #0 lore raw

Hello,

In 6.12.5+ kernels on AMD CPUs, we observe abnormally long boot times where the guest is struggling on PV spinlock initialization.

This occurs starting with 6.12.5, and also on more recent kernels on Intel platforms, but that hasn't been fully investigated at this time (but I assume it's a variant of the same issue).

This occurs since a backport of 76031d9 ("clocksource: Make negative motion detection more robust").

Some (claude-based) analysis made appears to relate that to the lack of proper max_raw_delta in the jiffies clocksource which appears to make the clock fail to progress meaningfully.

Here is a raw summary of the analysis

Quoted 1 line

We tracked it down to a single stable backport in 6.12.5: commit 1a678f6829a8 ("clocksource: Make negative motion detection more robust", upstream 76031d9536a0). It introduces a max_raw_delta field on struct clocksource but never initializes it for the default boot timekeeper (the jiffies clocksource), so clocksource_delta() clamps every delta to 0 and CLOCK_MONOTONIC freezes while that clocksource is active. On this HVM guest, SMP bring-up runs while the jiffies clocksource is still the timekeeper, and the Xen single shot (high resolution) tick then advances jiffies far too slowly, so the secondary CPUs burn seconds in calibrate_delay().

Teddy

Juergen Gross

2026-06-08 10:57 UTC #1 lore raw

Add Thomas Gleixner (author of the patch introducing the regression).

Juergen

Quoted 15 lines · Teddy Astie

Hello,
In 6.12.5+ kernels on AMD CPUs, we observe abnormally long boot times where the guest is struggling on PV spinlock initialization.
This occurs starting with 6.12.5, and also on more recent kernels on Intel platforms, but that hasn't been fully investigated at this time (but I assume it's a variant of the same issue).
This occurs since a backport of 76031d9 ("clocksource: Make negative motion detection more robust").
Some (claude-based) analysis made appears to relate that to the lack of proper max_raw_delta in the jiffies clocksource which appears to make the clock fail to progress meaningfully.
Here is a raw summary of the analysis
Quoted 1 line
We tracked it down to a single stable backport in 6.12.5: commit 1a678f6829a8
("clocksource: Make negative motion detection more robust", upstream 76031d9536a0). It introduces a max_raw_delta field on struct clocksource but never initializes it for the default boot timekeeper (the jiffies clocksource), so clocksource_delta() clamps every delta to 0 and CLOCK_MONOTONIC freezes while that clocksource is active. On this HVM guest, SMP bring-up runs while the jiffies clocksource is still the timekeeper, and the Xen single shot (high resolution) tick then advances jiffies far too slowly, so the secondary CPUs burn seconds in calibrate_delay().
Teddy

Thomas Gleixner

2026-06-08 15:13 UTC #2 lore raw

In reply to Teddy Astie

Quoted 14 lines · Teddy Astie

In 6.12.5+ kernels on AMD CPUs, we observe abnormally long boot times where the guest is struggling on PV spinlock initialization.
This occurs starting with 6.12.5, and also on more recent kernels on Intel platforms, but that hasn't been fully investigated at this time (but I assume it's a variant of the same issue).
This occurs since a backport of 76031d9 ("clocksource: Make negative motion detection more robust").
Some (claude-based) analysis made appears to relate that to the lack of proper max_raw_delta in the jiffies clocksource which appears to make the clock fail to progress meaningfully.

Quoted 7 lines

Here is a raw summary of the analysis
Quoted 1 line
We tracked it down to a single stable backport in 6.12.5: commit
1a678f6829a8 ("clocksource: Make negative motion detection more robust", upstream 76031d9536a0). It introduces a max_raw_delta field on struct clocksource but never initializes it for the default boot timekeeper (the jiffies clocksource), so clocksource_delta() clamps every delta to 0 and CLOCK_MONOTONIC freezes while that clocksource is active.

Bah. jiffies clocksource is registered way _after_ timekeeping started to use it.

The untested below should fix that.

Thanks,

tglx
---

kernel/time/jiffies.c +1 -7

@@ -60,15 +60,9 @@ EXPORT_SYMBOL(get_jiffies_64);
 
 EXPORT_SYMBOL(jiffies);
 
-static int __init init_jiffies_clocksource(void)
-{
-	return __clocksource_register(&clocksource_jiffies);
-}
-
-core_initcall(init_jiffies_clocksource);
-
 struct clocksource * __init __weak clocksource_default_clock(void)
 {
+	clocksource_register(&clocksource_jiffies);
 	return &clocksource_jiffies;
 }

Thomas Gleixner

2026-06-08 21:29 UTC #3 lore raw

Quoted 23 lines · Thomas Gleixner

Quoted 14 lines · Teddy Astie
In 6.12.5+ kernels on AMD CPUs, we observe abnormally long boot times where the guest is struggling on PV spinlock initialization.
This occurs starting with 6.12.5, and also on more recent kernels on Intel platforms, but that hasn't been fully investigated at this time (but I assume it's a variant of the same issue).
This occurs since a backport of 76031d9 ("clocksource: Make negative motion detection more robust").
Some (claude-based) analysis made appears to relate that to the lack of proper max_raw_delta in the jiffies clocksource which appears to make the clock fail to progress meaningfully.
Quoted 7 lines
Here is a raw summary of the analysis
Quoted 1 line
We tracked it down to a single stable backport in 6.12.5: commit
1a678f6829a8 ("clocksource: Make negative motion detection more robust", upstream 76031d9536a0). It introduces a max_raw_delta field on struct clocksource but never initializes it for the default boot timekeeper (the jiffies clocksource), so clocksource_delta() clamps every delta to 0 and CLOCK_MONOTONIC freezes while that clocksource is active.

Quoted 4 lines

Bah. jiffies clocksource is registered way _after_ timekeeping started to use it.
The untested below should fix that.

That obviously needs to be:

kernel/time/jiffies.c +1 -7

@@ -60,15 +60,9 @@ EXPORT_SYMBOL(get_jiffies_64);
 
 EXPORT_SYMBOL(jiffies);
 
-static int __init init_jiffies_clocksource(void)
-{
-	return __clocksource_register(&clocksource_jiffies);
-}
-
-core_initcall(init_jiffies_clocksource);
-
 struct clocksource * __init __weak clocksource_default_clock(void)
 {
+	__clocksource_register(&clocksource_jiffies);
 	return &clocksource_jiffies;
 }

Teddy Astie

author

2026-06-09 09:27 UTC #4 lore raw

In reply to Thomas Gleixner

Le 08/06/2026 à 17:15, Thomas Gleixner a écrit :

Quoted 43 lines · Teddy Astie

Quoted 14 lines
In 6.12.5+ kernels on AMD CPUs, we observe abnormally long boot times where the guest is struggling on PV spinlock initialization.
This occurs starting with 6.12.5, and also on more recent kernels on Intel platforms, but that hasn't been fully investigated at this time (but I assume it's a variant of the same issue).
This occurs since a backport of 76031d9 ("clocksource: Make negative motion detection more robust").
Some (claude-based) analysis made appears to relate that to the lack of proper max_raw_delta in the jiffies clocksource which appears to make the clock fail to progress meaningfully.
Quoted 7 lines
Here is a raw summary of the analysis
Quoted 1 line
We tracked it down to a single stable backport in 6.12.5: commit
1a678f6829a8 ("clocksource: Make negative motion detection more robust", upstream 76031d9536a0). It introduces a max_raw_delta field on struct clocksource but never initializes it for the default boot timekeeper (the jiffies clocksource), so clocksource_delta() clamps every delta to 0 and CLOCK_MONOTONIC freezes while that clocksource is active.
Bah. jiffies clocksource is registered way _after_ timekeeping started to use it.
The untested below should fix that.
Thanks,
tglx
---
kernel/time/jiffies.c +0 -3
@@ -60,15 +60,9 @@ EXPORT_SYMBOL(get_jiffies_64);
 
  EXPORT_SYMBOL(jiffies);
 
-static int __init init_jiffies_clocksource(void)
-{
-	return __clocksource_register(&clocksource_jiffies);

kernel/time/jiffies.c EXPORT_SYMBOL(get_jiffies_64); · line 68

Quoted 10 lines

kernel/time/jiffies.c +1 -4

-}
-
-core_initcall(init_jiffies_clocksource);
-
  struct clocksource * __init __weak clocksource_default_clock(void)
  {
+	clocksource_register(&clocksource_jiffies);
  	return &clocksource_jiffies;
  }

Hmm, there's a case where clocksource_mutex gets taken twice (both in __clocksource_register_scale() (through clocksource_register()) and clocksource_done_booting()).

What about making clocksource_jiffies gain ->enable() to setup what ever needs to be (like calling __clocksource_update_freq_scale()) ?

Teddy

Thomas Gleixner

2026-06-09 15:14 UTC #5 lore raw

Quoted 13 lines · Teddy Astie

Le 08/06/2026 à 17:15, Thomas Gleixner a écrit :
Review
Quoted 8 lines
  struct clocksource * __init __weak clocksource_default_clock(void)
  {
(quoted diff) +1 -0
+	clocksource_register(&clocksource_jiffies);
  	return &clocksource_jiffies;
  }
Hmm, there's a case where clocksource_mutex gets taken twice (both in __clocksource_register_scale() (through clocksource_register()) and clocksource_done_booting()).

Bah.

Quoted 2 lines

What about making clocksource_jiffies gain ->enable() to setup what ever needs to be (like calling __clocksource_update_freq_scale()) ?

Doesn't work either.

Updated version below. It's not pretty, but it should cure your problem. If that's confirmed I think about a less ugly solution.

Thanks,

tglx
---

kernel/time/jiffies.c +5 -6

@@ -60,15 +60,14 @@ EXPORT_SYMBOL(get_jiffies_64);
 
 EXPORT_SYMBOL(jiffies);
 
-static int __init init_jiffies_clocksource(void)
-{
-	return __clocksource_register(&clocksource_jiffies);
-}
-
-core_initcall(init_jiffies_clocksource);
+static bool cs_jiffies_registered __initdata;
 
 struct clocksource * __init __weak clocksource_default_clock(void)
 {
+	if (!cs_jiffies_registered) {
+		__clocksource_register(&clocksource_jiffies);
+		cs_jiffies_registered = true;
+	}
 	return &clocksource_jiffies;
 }

tip-bot2 for Thomas Gleixner

merge bot Applied

2026-06-13 13:28 UTC #7 lore raw

[tip: timers/core] time/jiffies: Register jiffies clocksource before usage

In reply to Thomas Gleixner

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 <[email protected]>
AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
Committer:     Thomas Gleixner <[email protected]>
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 <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Tested-by Teddy Astie <[email protected]>

Cc [email protected]

Link https://patch.msgid.link/87y0gn3fve.ffs@fw13 open here

Closes https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech open here

---
 kernel/time/jiffies.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

kernel/time/jiffies.c +5 -6

index 1c954f3..d514288 100644
@@ -60,15 +60,14 @@ EXPORT_SYMBOL(get_jiffies_64);
 
 EXPORT_SYMBOL(jiffies);
 
-static int __init init_jiffies_clocksource(void)
-{
-	return __clocksource_register(&clocksource_jiffies);
-}
-
-core_initcall(init_jiffies_clocksource);
+static bool cs_jiffies_registered __initdata;
 
 struct clocksource * __init __weak clocksource_default_clock(void)
 {
+	if (!cs_jiffies_registered) {
+		__clocksource_register(&clocksource_jiffies);
+		cs_jiffies_registered = true;
+	}
 	return &clocksource_jiffies;
 }

Marek Szyprowski

2026-06-16 18:47 UTC #8 lore raw

Re: [tip: timers/core] time/jiffies: Register jiffies clocksource before usage

Dear All,

Quoted 20 lines · 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 <[email protected]>
AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
Committer:     Thomas Gleixner <[email protected]>
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().

Quoted 7 lines

Fixes 76031d9536a0 ("clocksource: Make negative motion detection more robust")
Reported-by Teddy Astie <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Tested-by Teddy Astie <[email protected]>
Cc [email protected]
Link https://patch.msgid.link/87y0gn3fve.ffs@fw13 open here
Closes https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech open here

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.

Quoted 19 lines

---
 kernel/time/jiffies.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

kernel/time/jiffies.c +1 -6

index 1c954f3..d514288 100644
@@ -60,15 +60,14 @@ EXPORT_SYMBOL(get_jiffies_64);
 
 EXPORT_SYMBOL(jiffies);
 
-static int __init init_jiffies_clocksource(void)
-{
-	return __clocksource_register(&clocksource_jiffies);
-}
-
-core_initcall(init_jiffies_clocksource);
+static bool cs_jiffies_registered __initdata;

kernel/time/jiffies.c EXPORT_SYMBOL(get_jiffies_64); · line 73

Quoted 10 lines

kernel/time/jiffies.c +4 -0

 
 struct clocksource * __init __weak clocksource_default_clock(void)
 {
+	if (!cs_jiffies_registered) {
+		__clocksource_register(&clocksource_jiffies);
+		cs_jiffies_registered = true;
+	}
 	return &clocksource_jiffies;
 }

Best regards

Signature · 2 lines

Marek Szyprowski, PhD
Samsung R&D Institute Poland

Conor Dooley

2026-06-17 14:17 UTC #9 lore raw

Re: [tip: timers/core] time/jiffies: Register jiffies clocksource before usage

Quoted 63 lines · Marek Szyprowski

Dear All,
Quoted 20 lines · 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 <[email protected]>
AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
Committer:     Thomas Gleixner <[email protected]>
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().
Quoted 7 lines
Fixes 76031d9536a0 ("clocksource: Make negative motion detection more robust")
Reported-by Teddy Astie <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Tested-by Teddy Astie <[email protected]>
Cc [email protected]
Link https://patch.msgid.link/87y0gn3fve.ffs@fw13 open here
Closes https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech open here
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

Quoted 5 lines

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] [<ffffffff8001c0e0>] dump_backtrace+0x1c/0x24
[    0.000000] [<ffffffff80002526>] show_stack+0x28/0x34
[    0.000000] [<ffffffff800135a0>] dump_stack_lvl+0x60/0x88
[    0.000000] [<ffffffff800135dc>] dump_stack+0x14/0x1c
[    0.000000] [<ffffffff800bb096>] __lock_acquire+0x81c/0x234e
[    0.000000] [<ffffffff800bd924>] lock_acquire+0x2e0/0x460
[    0.000000] [<ffffffff80d61d46>] mutex_lock_nested+0x44/0x8a
[    0.000000] [<ffffffff8012e704>] __clocksource_register_scale+0x222/0x306
[    0.000000] [<ffffffff80e15572>] clocksource_default_clock+0x48/0x62
[    0.000000] [<ffffffff80e15286>] timekeeping_init+0x1b6/0x25e
[    0.000000] [<ffffffff80e00f9c>] 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.

Thomas Gleixner

2026-06-17 15:04 UTC #10 lore raw

Re: [tip: timers/core] time/jiffies: Register jiffies clocksource before usage

Quoted 2 lines · Conor Dooley

On Tue, Jun 16, 2026 at 08:47:00PM +0200, Marek Szyprowski wrote:
Same here:

Fix is queued

Thomas Gleixner

2026-06-17 15:04 UTC #11 lore raw

Re: [tip: timers/core] time/jiffies: Register jiffies clocksource before usage

In reply to Marek Szyprowski

Quoted 28 lines · Marek Szyprowski

Quoted 20 lines · 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 <[email protected]>
AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
Committer:     Thomas Gleixner <[email protected]>
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().
Quoted 7 lines
Fixes 76031d9536a0 ("clocksource: Make negative motion detection more robust")
Reported-by Teddy Astie <[email protected]>
Signed-off-by Thomas Gleixner <[email protected]>
Tested-by Teddy Astie <[email protected]>
Cc [email protected]
Link https://patch.msgid.link/87y0gn3fve.ffs@fw13 open here
Closes https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech open here

Quoted 4 lines

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):

Fix is queued already.