[PATCH v4 0/3] cyclic/watchdog patches

[Tom Rini]

On Tue, May 21, 2024 at 01:54:58PM +0200, Stefan Roese wrote:
> 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?

In Azure (and not GitLab) we seem to have some tests that fail when (I
speculate..) we get put on busy or slow resources for the job. When I
last looked, retryCountOnTaskFailure was limited to 2 at most. I would
be open to other suggestions / patches (such as yes, increasing the
threshold in a test) to make the pipeline more reliable.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240521/e722ff80/attachment.sig>