Booting v7.1-rc4 hangs on a single core CPU, bisected to ff1c0c5d07028

Booting v7.1-rc4 hangs on a single core CPU, bisected to ff1c0c5d07028

[Indrek Kruusa]

Hi,

booting Linux 7.1-rc4 on my Allwinner D1 (single core RISC-V) board
hangs during boot.
The last messages are MMC related, but further testing revealed that
the system hangs at  msleep()/usleep_range() calls.

I did an assisted bisect which points to this merge commit:
ff1c0c5d07028 Merge branch 'timers/urgent' into timers/core

I tried the suggested workaround "revert clockevents.c to the version
from 09c04714cb455" and it fixed the problem for me.

Can anyone with a single-core (RISC-V?) system confirm this? It seems
to be no issue on SMP.

Best regards,
Indrek

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] clocksource/drivers/timer-sun4i: Advertise a real minimum delta

[Felix Yan]

sun4i_clkevt_next_event() compensates for the timer stop/start
synchronization delay by programming evt - TIMER_SYNC_TICKS into the
hardware interval register. The clockevent device currently advertises
TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed
to call set_next_event() with evt == TIMER_SYNC_TICKS.

That programs a zero-tick interval. With oneshot/highres/nohz timer
operation this can leave the next event stuck, which was observed as a
boot hang on Allwinner D1 after the clockevents core started reusing
forced minimum-delta events.

Advertise one extra tick instead, so the smallest event accepted by the
core still programs at least one hardware tick after the synchronization
compensation.

Fixes: 12e1480bcb49 ("clocksource: sun4i: Report the minimum tick that we can program")
Cc: stable@vger.kernel.org
Reported-by: Indrek Kruusa <indrek.kruusa@gmail.com>
Closes: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/
Assisted-by: Codex:gpt-5.5
Signed-off-by: Felix Yan <felixonmars@archlinux.org>
---
 drivers/clocksource/timer-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/timer-sun4i.c b/drivers/clocksource/timer-sun4i.c
index 7bdcc60ad43c..c2d04ab7cf2d 100644
--- a/drivers/clocksource/timer-sun4i.c
+++ b/drivers/clocksource/timer-sun4i.c
@@ -208,7 +208,7 @@ static int __init sun4i_timer_init(struct device_node *node)
 	sun4i_timer_clear_interrupt(timer_of_base(&to));
 
 	clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
-					TIMER_SYNC_TICKS, 0xffffffff);
+					TIMER_SYNC_TICKS + 1, 0xffffffff);
 
 	/* Enable timer0 interrupt */
 	val = readl(timer_of_base(&to) + TIMER_IRQ_EN_REG);
-- 
2.54.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH] clocksource/drivers/timer-sun4i: Advertise a real minimum delta

[Felix Yan]

sun4i_clkevt_next_event() compensates for the timer stop/start
synchronization delay by programming evt - TIMER_SYNC_TICKS into the
hardware interval register. The clockevent device currently advertises
TIMER_SYNC_TICKS as min_delta_ticks, so the clockevents core is allowed
to call set_next_event() with evt == TIMER_SYNC_TICKS.

That programs a zero-tick interval. With oneshot/highres/nohz timer
operation this can leave the next event stuck, which was observed as a
boot hang on Allwinner D1 after the clockevents core started reusing
forced minimum-delta events.

Advertise one extra tick instead, so the smallest event accepted by the
core still programs at least one hardware tick after the synchronization
compensation.

Fixes: 12e1480bcb49 ("clocksource: sun4i: Report the minimum tick that we can program")
Cc: stable@vger.kernel.org
Reported-by: Indrek Kruusa <indrek.kruusa@gmail.com>
Closes: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/
Assisted-by: Codex:gpt-5.5
Signed-off-by: Felix Yan <felixonmars@archlinux.org>
---
 drivers/clocksource/timer-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/timer-sun4i.c b/drivers/clocksource/timer-sun4i.c
index 7bdcc60ad43c..c2d04ab7cf2d 100644
--- a/drivers/clocksource/timer-sun4i.c
+++ b/drivers/clocksource/timer-sun4i.c
@@ -208,7 +208,7 @@ static int __init sun4i_timer_init(struct device_node *node)
 	sun4i_timer_clear_interrupt(timer_of_base(&to));
 
 	clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
-					TIMER_SYNC_TICKS, 0xffffffff);
+					TIMER_SYNC_TICKS + 1, 0xffffffff);
 
 	/* Enable timer0 interrupt */
 	val = readl(timer_of_base(&to) + TIMER_IRQ_EN_REG);
-- 
2.54.0

Re: [PATCH] clocksource/drivers/timer-sun4i: Advertise a real minimum delta

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] The exact same zero-tick interval bug fixed in timer-sun4i.c is present and unfixed in the sibling driver timer-sun5i.c.
- [High] The tick_resume callback can cause an infinite loop and hard lockup if the timer IP loses state during suspend.
- [High] sun4i_clkevt_set_oneshot() enables the hardware timer without programming a safe interval, which can cause a boot hang if the hardware interval register defaults to zero.
--

commit 58b9ac36774c7659ade7328ca0fd561f9759e49e
Author: Felix Yan <felixonmars@archlinux.org>
Subject: clocksource/drivers/timer-sun4i: Advertise a real minimum delta

This commit modifies the sun4i timer driver to advertise one extra tick for
the minimum delta. This prevents the clockevents core from requesting a
next event of exactly TIMER_SYNC_TICKS, which would result in programming a
zero-tick interval and hanging the hardware on Allwinner D1.

Link: https://lore.kernel.org/linux-riscv/CA+fTLhgLmTY+exGujKf8OYYQvcEW5X5NJ_5sLq2AYL6zER2c0A@mail.gmail.com/

> diff --git a/drivers/clocksource/timer-sun4i.c b/drivers/clocksource/timer-sun4i.c
> index 7bdcc60ad43cb..c2d04ab7cf2d3 100644
> --- a/drivers/clocksource/timer-sun4i.c
> +++ b/drivers/clocksource/timer-sun4i.c
> @@ -208,7 +208,7 @@ static int __init sun4i_timer_init(struct device_node *node)
>  	sun4i_timer_clear_interrupt(timer_of_base(&to));
>  
>  	clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
> -					TIMER_SYNC_TICKS, 0xffffffff);
> +					TIMER_SYNC_TICKS + 1, 0xffffffff);

[Severity: High]
This is a pre-existing issue, but the exact same zero-tick interval bug
appears to be present in the sibling driver timer-sun5i.c.

In drivers/clocksource/timer-sun5i.c:sun5i_setup_clockevent(), the device
is registered with a minimum delta of TIMER_SYNC_TICKS:

    clockevents_config_and_register(&ce->clkevt, rate,
                                    TIMER_SYNC_TICKS, 0xffffffff);

When the clockevents core requests exactly this length,
sun5i_clkevt_next_event() subtracts TIMER_SYNC_TICKS, resulting in 0:

    sun5i_clkevt_time_setup(ce, 0, evt - TIMER_SYNC_TICKS);

Should timer-sun5i.c be brought up to parity to prevent an identically
triggered hang there?


[Severity: High]
This isn't a bug introduced by this patch, but could this zero-tick hardware
hang also trigger via the oneshot configuration path in timer-sun4i.c?

When the clockevents core switches the timer state,
sun4i_clkevt_set_oneshot() calls:

    sun4i_clkevt_time_start(timer_of_base(to), 0, false);

This enables the timer without programming a valid non-zero interval, which
reloads the current uninitialized value of TIMER_INTVAL_REG(0).

If this defaults to 0 (the power-on reset default), does this risk the exact
same hardware hang?


[Severity: High]
This is a pre-existing issue, but can the timer sync logic cause a hard
lockup during system resume?

In drivers/clocksource/timer-sun4i.c, the tick_resume callback is mapped to
sun4i_clkevt_shutdown:

    .tick_resume = sun4i_clkevt_shutdown,

This calls sun4i_clkevt_time_stop() followed by sun4i_clkevt_sync(), which
spins infinitely waiting for Timer 1 to advance:

    while ((old - readl(base + TIMER_CNTVAL_REG(1))) < TIMER_SYNC_TICKS)
            cpu_relax();

If the timer block lost power during system suspend, Timer 1 will be
disabled upon resume. Since there is no suspend/resume hook to restart
Timer 1, the counter will never change.

Will this result in a deadlock?

>  
>  	/* Enable timer0 interrupt */
>  	val = readl(timer_of_base(&to) + TIMER_IRQ_EN_REG);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624220434.4183732-1-felixonmars@archlinux.org?part=1