[REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Teddy Astie]

[-- Attachment #1.1.1: Type: text/plain, Size: 1354 bytes --]

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2489 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: [REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1535 bytes --]

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


Juergen

On 08.06.26 12:29, Teddy Astie wrote:
> 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
>  > 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


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Thomas Gleixner]

On Mon, Jun 08 2026 at 12:29, Teddy Astie wrote:
> 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
>  > 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
---
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -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;
 }
 

Re: [REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Thomas Gleixner]

On Mon, Jun 08 2026 at 17:13, Thomas Gleixner wrote:
> On Mon, Jun 08 2026 at 12:29, Teddy Astie wrote:
>> 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
>>  > 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.

That obviously needs to be:

--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -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;
 }
 

Re: [REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Teddy Astie]

[-- Attachment #1.1.1: Type: text/plain, Size: 2267 bytes --]

Le 08/06/2026 à 17:15, Thomas Gleixner a écrit :
> On Mon, Jun 08 2026 at 12:29, Teddy Astie wrote:
>> 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
>>   > 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
> ---
> --- a/kernel/time/jiffies.c
> +++ b/kernel/time/jiffies.c
> @@ -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;
>   }
>   
> 
> 

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2489 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: [REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Thomas Gleixner]

On Tue, Jun 09 2026 at 11:27, Teddy Astie wrote:
> Le 08/06/2026 à 17:15, Thomas Gleixner a écrit :
>>   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()).

Bah.

> 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
---
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -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;
 }
 

Re: [REGRESSION][BISECTED] Long boot time with Xen HVM guests during PV spinlock initialization

[Teddy Astie]

[-- Attachment #1.1.1: Type: text/plain, Size: 1596 bytes --]

Le 09/06/2026 à 17:17, Thomas Gleixner a écrit :
> On Tue, Jun 09 2026 at 11:27, Teddy Astie wrote:
>> Le 08/06/2026 à 17:15, Thomas Gleixner a écrit :
>>>    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()).
> 
> Bah.
> 
>> 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
> ---
> --- a/kernel/time/jiffies.c
> +++ b/kernel/time/jiffies.c
> @@ -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;
>   }
>   
> 

Yes, that fixes it.

Teddy

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2489 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

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

[tip-bot2 for 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 <tglx@kernel.org>
AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
Committer:     Thomas Gleixner <tglx@kernel.org>
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 <teddy.astie@vates.tech>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Teddy Astie <teddy.astie@vates.tech>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/87y0gn3fve.ffs@fw13
Closes: https://lore.kernel.org/all/1780914594.8631fc262581453bbf619ec5b2062170.19ea6c8227b000701b@vates.tech
---
 kernel/time/jiffies.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index 1c954f3..d514288 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -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;
 }
 

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

[Marek Szyprowski]

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 <tglx@kernel.org>
> AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
> Committer:     Thomas Gleixner <tglx@kernel.org>
> 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 <teddy.astie@vates.tech>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Tested-by: Teddy Astie <teddy.astie@vates.tech>
> 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.


> ---
>  kernel/time/jiffies.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
> index 1c954f3..d514288 100644
> --- a/kernel/time/jiffies.c
> +++ b/kernel/time/jiffies.c
> @@ -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;
>  }
>  

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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5226 bytes --]

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 <tglx@kernel.org>
> > AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
> > Committer:     Thomas Gleixner <tglx@kernel.org>
> > 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 <teddy.astie@vates.tech>
> > Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> > Tested-by: Teddy Astie <teddy.astie@vates.tech>
> > 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] [<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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Thomas Gleixner]

On Tue, Jun 16 2026 at 20:47, Marek Szyprowski wrote:
> 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 <tglx@kernel.org>
>> AuthorDate:    Tue, 09 Jun 2026 17:14:45 +02:00
>> Committer:     Thomas Gleixner <tglx@kernel.org>
>> 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 <teddy.astie@vates.tech>
>> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
>> Tested-by: Teddy Astie <teddy.astie@vates.tech>
>> 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):

Fix is queued already.

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

[Thomas Gleixner]

On Wed, Jun 17 2026 at 15:17, Conor Dooley wrote:
> On Tue, Jun 16, 2026 at 08:47:00PM +0200, Marek Szyprowski wrote:
> Same here:

Fix is queued