From: Rasmus Villemoes <rv@rasmusvillemoes.dk>
To: "Marek Vasut" <marek.vasut@mailbox.org>
Cc: "Emanuele Ghidoli" <ghidoliemanuele@gmail.com>,
"Tom Rini" <trini@konsulko.com>,
"Patrice Chotard" <patrice.chotard@foss.st.com>,
u-boot@lists.u-boot-project.org, "Peng Fan" <peng.fan@nxp.com>,
"Stefan Roese" <stefan.roese@mailbox.org>
Subject: Re: Regression on colibri-imx7 due to commit 9c1b13b3fd27 ("cyclic: reduce get_timer_us() calls inside hlist_for_each_entry_safe()")
Date: Fri, 24 Jul 2026 09:05:24 +0200 [thread overview]
Message-ID: <87a4rgrhor.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <0c11f834-7b7a-4e94-90b3-23de79040b4a@mailbox.org> (Marek Vasut's message of "Fri, 24 Jul 2026 02:00:08 +0200")
On Fri, Jul 24 2026, "Marek Vasut" <marek.vasut@mailbox.org> wrote:
> On 7/23/26 10:41 PM, Emanuele Ghidoli wrote:
>>
>>
>> On 7/23/26 20:35, Marek Vasut wrote:
>>> On 7/23/26 4:53 PM, Emanuele Ghidoli wrote:
>>>
>>> Hello everyone,
>>>
>>>> I found that Colibri iMX7 no longer boots when commit 9c1b13b3fd27
>>>> ("cyclic: reduce get_timer_us() calls inside hlist_for_each_entry_safe()")
>>>> is applied. Nothing is printed on the serial.
>>>>
>>>> I bisected the issue: booting the parent commit works fine, and
>>>> reverting this patch on top of current main also restores
>>>> boot. It's not yet obvious to me what in this change causes the
>>>> regression.
>>>>
>>>> Would it make sense to revert it until the root cause is found?
>>>
>>> Give Patrice a bit of time to analyze the problem.
>>>
>>
>> Hello,
>>
>> after the regression, get_timer_us() is called on every cyclic_run() call,
>> even when the cyclic list is empty. On imx7 this happens earlier than before,
>> when the timer has not yet been initialized: get_timer_us() calls get_tbclk(),
>> whose value is zero, and uses it as a divisor in tick_to_time_us(), leading to
>> a division by zero.
>>
>> I would fix this by ensuring get_tbclk() returns at least 1 on imx7, but we
>> could hide bugs in this way. However, this bug could also be present on other
>> architectures, so I would just guard against entering the cyclic loop by
>> checking whether the list is empty before doing anything else, so
>> get_timer_us() is called "at the same point in time" as before.
>> Something like:
>> if (hlist_empty(cyclic_get_list())) {
>> gd->flags &= ~GD_FLG_CYCLIC_RUNNING;
>> return;
>> }
> It looks like there are two topics -- optimize the cyclic run and fix
> the MX7 timer.
>
> I agree the cyclic run should exit if the list is empty, but please wait
> for input from Rasmus on that.
>
Yes, we could/should definitely exit early if the list is empty, but
don't mix it up with the GD_FLG_CYCLIC_RUNNING bit. Just add it as a
separate early exit condition. But a future reader might read that as
"just" an optimization, seeing that the loop would just do nothing, I
think it also requires an explanation. Something like
diff --git a/common/cyclic.c b/common/cyclic.c
index 573e715587d..e46346536ab 100644
--- a/common/cyclic.c
+++ b/common/cyclic.c
@@ -69,6 +69,19 @@ static void cyclic_run(void)
struct hlist_node *tmp;
u64 now, after, cpu_time;
+ /*
+ * Nothing to do if the list is empty. Also, schedule() can be
+ * called before timer infrastructure is ready, in which case
+ * calling get_timer_us() before the (empty) loop could cause
+ * a divide-by-0 or otherwise crash the system. No clients
+ * should be registered before the timer infrastructure is up,
+ * so the check for the list being empty should be
+ * ok. Otherwise, we would need a new GD_FLG_TIMERS_READY
+ * flag.
+ */
+ if (hlist_empty(cyclic_get_list()))
+ return;
+
/* Prevent recursion */
if (gd->flags & GD_FLG_CYCLIC_RUNNING)
return;
Completely unrelated, but now that I see a new use of that
cyclic_get_list() helper, I think it's time to get rid of that and just
spell it &gd->cyclic_list. It was only needed back when gd was
volatile-qualified.
Rasmus
next prev parent reply other threads:[~2026-07-24 7:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 14:53 Regression on colibri-imx7 due to commit 9c1b13b3fd27 ("cyclic: reduce get_timer_us() calls inside hlist_for_each_entry_safe()") Emanuele Ghidoli
2026-07-23 18:35 ` Marek Vasut via U-Boot
2026-07-23 20:41 ` Emanuele Ghidoli
2026-07-24 0:00 ` Marek Vasut via U-Boot
2026-07-24 7:05 ` Rasmus Villemoes [this message]
2026-07-24 7:36 ` Emanuele Ghidoli
2026-07-26 6:41 ` Marek Vasut via U-Boot
2026-07-28 9:46 ` Emanuele Ghidoli
2026-07-28 11:53 ` Marek Vasut via U-Boot
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=87a4rgrhor.fsf@rasmusvillemoes.dk \
--to=rv@rasmusvillemoes.dk \
--cc=ghidoliemanuele@gmail.com \
--cc=marek.vasut@mailbox.org \
--cc=patrice.chotard@foss.st.com \
--cc=peng.fan@nxp.com \
--cc=stefan.roese@mailbox.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.u-boot-project.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.