From: Andreas Larsson <andreas@gaisler.com>
To: Stian Halseth <stian@itx.no>,
tglx@kernel.org, davem@davemloft.net, sparclinux@vger.kernel.org
Cc: Tony Rodriguez <unixpro1970@gmail.com>,
linux-kernel@vger.kernel.org, thomas.weissschuh@linutronix.de,
regressions@lists.linux.dev, glaubitz@physik.fu-berlin.de,
linux@leemhuis.info, torvalds@linux-foundation.org
Subject: Re: [PATCH v3] sparc64: Fix comparator problem with timer interrupts
Date: Wed, 7 Oct 2026 07:56:59 +0200 [thread overview]
Message-ID: <8f605908-3315-4e05-b30a-5f298f93635e@gaisler.com> (raw)
In-Reply-To: <20260831180728.3097740-1-stian@itx.no>
On 2026-08-31 20:07, Stian Halseth wrote:
> From: Tony Rodriguez <unixpro1970@gmail.com>
>
> The tick/stick/hbtick add_compare() implementations program the
> comparator and then check whether the write took effect in time:
>
> exp = read_cnt() + delta_ticks;
> write_cmp(exp);
> return (read_cnt() - exp) > 0;
>
> A nonzero return value means the expiry time was already reached
> before the comparator write could take effect, so the interrupt may
> never fire, and the caller retries with a new expiry:
>
> return tick.add_compare(delta_ticks) ? -ETIME : 0;
>
> The check only fails the write when the counter has advanced past the
> expiry time, but not when it is equal to it. In the equal case it is
> unknown whether the comparator write took effect before or after the
> counter reached the expiry value, so the compare match - and with it
> the timer interrupt - may have been missed. add_compare() then
> reports success, the caller does not retry, and the CPU is left with
> no pending timer interrupt.
>
> This results in stalled hrtimers and RCU stalls / hangs under load,
> observed on SPARC S7-2 and T7-1 systems:
>
> rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> rcu: rcu_sched kthread timer wakeup didn't happen for 5259 jiffies!
> rcu: Possible timer handling issue on cpu=100 timer-softirq=15
>
> Treat counter == expiry as failure as well, so the caller retries
> with a new expiry time. After this change S7-2 and T7-1 systems no
> longer hang.
>
> Diagnosed-by: Thomas Gleixner <tglx@kernel.org>
> Link: https://lore.kernel.org/all/87tssb6olo.ffs@tglx/
> Link: https://lore.kernel.org/all/871pfcznw0.ffs@tglx/
> Link: https://lore.kernel.org/all/20260519022421.5978-1-unixpro1970@gmail.com/
> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> [stian: rewrote the changelog per review of v2, retested]
> Signed-off-by: Stian Halseth <stian@itx.no>
> ---
> v3:
> - rewrite the changelog: describe the write/readback ordering and the
> direction of the equal-compare case per Thomas Gleixner's review
> https://lore.kernel.org/all/878q9fxywc.ffs@tglx/
> (the code change is identical to v2)
> - add the Link: tags to the original debugging discussion
> - picked up with Tony's agreement after v2 stalled
> https://lore.kernel.org/all/10382506-3f57-4b33-8356-34f23fb5f153@gmail.com/
>
> Tested on an UltraSPARC T4-1 (sun4v, stick variant): 9.1M hrtimer
> reprograms in 90s across 32 threads with 10-500us expiries, no
> stalls, no lost wakeups (worst oversleep 657us).
>
> arch/sparc/kernel/time_64.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
> --- a/arch/sparc/kernel/time_64.c
> +++ b/arch/sparc/kernel/time_64.c
> @@ -146,7 +146,7 @@
> : "=r" (new_tick));
> new_tick &= ~TICKCMP_IRQ_BIT;
>
> - return ((long)(new_tick - (orig_tick+adj))) > 0L;
> + return ((long)(new_tick - (orig_tick+adj))) >= 0L;
> }
>
> static unsigned long tick_add_tick(unsigned long adj)
> @@ -277,7 +277,7 @@
> : "=r" (new_tick));
> new_tick &= ~TICKCMP_IRQ_BIT;
>
> - return ((long)(new_tick - (orig_tick+adj))) > 0L;
> + return ((long)(new_tick - (orig_tick+adj))) >= 0L;
> }
>
> static unsigned long stick_get_frequency(void)
> @@ -411,7 +411,7 @@
>
> val2 = __hbird_read_stick() & ~TICKCMP_IRQ_BIT;
>
> - return ((long)(val2 - val)) > 0L;
> + return ((long)(val2 - val)) >= 0L;
> }
>
> static unsigned long hbtick_get_frequency(void)
> --
> 2.53.0
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Picking this up to my for-next.
Thanks,
Andreas
prev parent reply other threads:[~2026-10-07 5:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 2:24 [PATCH v2 1/1] " Tony Rodriguez
2026-05-19 2:24 ` Tony Rodriguez
2026-05-19 14:22 ` Thomas Gleixner
2026-05-19 23:25 ` Tony Rodriguez
2026-08-31 18:07 ` [PATCH v3] " Stian Halseth
2026-09-28 22:17 ` Stian Halseth
2026-10-07 5:56 ` Andreas Larsson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f605908-3315-4e05-b30a-5f298f93635e@gaisler.com \
--to=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=stian@itx.no \
--cc=tglx@kernel.org \
--cc=thomas.weissschuh@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=unixpro1970@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®