[PATCH v4 0/3] cyclic/watchdog patches

[Stefan Roese]

On 5/21/24 11:47, Rasmus Villemoes wrote:
> On 21/05/2024 10.46, Rasmus Villemoes wrote:
>> A bit of a mixed bag. I've been wanting to submit something like 3/3
>> for a while. So when I stumbled on Marek's patch
>> https://lore.kernel.org/u-boot/20240316201416.211480-1-marek.vasut+renesas@mailbox.org/
>> , I got reminded of that plan, and I think that patch could be more
>> readable if we adopt this model.
>>
>> While actually doing those mostly mechanical changes, I stumbled on
>> two separate issues that probably want fixing regardless of the fate
>> of 3/3.
>>
>> Mostly just compile-tested, and now also checked that at least the
>> sandbox test runs succesfully, and that it builds both with and
>> without CONFIG_CYCLIC.
> 
> So I managed to trigger an azure test by pushing to github and creating
> a dummy PR: https://github.com/u-boot/u-boot/pull/542
> 
> That fails, and while it involves the cyclic framework, I'm pretty sure
> these patches are not to blame, since the same error also exists in
> other pipelines. It's an "expect" failure, because some watchdog
> callback apparently sometimes takes more than 1ms, so the default 1000us
> threshold is exceeded, and that prints a warning which breaks the "expect".
> 
> An example is
> 
> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=8459&view=logs&j=a1270dec-081b-5c65-5cd5-5e915a842596&t=69f6cf72-86f3-551a-807d-f28f62a1426f&l=1055
> .
> 
> I don't know why it only/mostly seems to happen in clang builds, but I
> think the fact that these happen quite frequently warrants either
> bumping the threshold used in the CI builds quite a lot, or adding a
> config option to suppress that warning/limit altogether for CI builds.

I've also seen CI build issues from time to time and restarting the
build magically solved these issues. I'm all for making this CI
build more stable, perhaps Tom has some ideas?

Regarding this cyclic patch:

Still some problems, MIPS64 related at least, octeon_nic23 target:

https://dev.azure.com/sr0718/0cded7c3-6e6a-4b57-8d0f-65c99496c42f/_apis/build/builds/357/logs/415

Thanks,
Stefan