Re: [Buildroot] [PATCH 1/1] package/kexec: bump to version 2.0.29

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello Julien,

On Sun, 28 Jul 2024 15:09:38 +0200
Julien Olivain <ju.o@free.fr> wrote:

> Unfortunately, I cannot reproduce this issue.
> 
> I tested many configurations:
> - at the runtime test failure (commit 6282b4ec),
> - before the kexec-2.0.29 bump (commit acdcc4c~1),
> - at the kexec-2.0.29 bump (commit acdcc4c),
> 
> I did those test on idle host and loaded host, inside the Docker image
> and outside (on Fedora 40). I never set a timeout_multiplier.
> 
> In all cases, the test succeed (in idle host cases) or sometimes
> failed with a clean timeout (on highly loaded host).
> 
> My guess right now is that this execution happened on a very loaded
> runner. The failed job reports 27 minutes of build/execution. As a
> reference, this test succeed in ~6 mins on my idle laptop.

Thanks for having investigated this!

> This slow execution might trigger an actual kexec-tools or kernel
> bug/corner case.
> 
> To better debug those tricky situations, I would suggest to add few
> extra info in the runtime test run log. Namely, the number of cpus of
> the runner, the system load at the time of the test startup, and the
> value of the timeout_multiplier used for the execution. Something
> like adding in support/testing/infra/emulator.py, in boot() :
> 
>      self.logfile.write(f"> host cpu count: {os.cpu_count()}\n")  
>      ldavg = os.getloadavg()
>      ldavg_str = f"{ldavg[0]:.2f}, {ldavg[1]:.2f}, {ldavg[2]:.2f}"
>      self.logfile.write(f"> host loadavg: {ldavg_str}\n")
>      self.logfile.write(f"> timeout multiplier:   
> {self.timeout_multiplier}\n")
> 
> just before the line:
> 
>      self.logfile.write("> starting qemu with '%s'\n" % "   
> ".join(qemu_cmd))
> 
> What do you think?  If you agree, I can send a patch for this.

Makes sense to me, so feel free to send a patch for this.

> Before continuing debugging, I would like to see other executions
> in the CI.

From what I can see, the previous runs of our test cases in the CI did
not encountered any issue with the Kexec test, so it could indeed be a
spurious issue.

Did you know that you can also run the runtime test cases in Gitlab CI
on your side? You need a Gitlab account of course, then fork the
Buildroot repo in your Gitlab account, and push a branch to your Gitlab
Buildroot repo that has a name like this:
whateveryouwant-tests.package.test_kexec.TestKexec and tada, it will
run the kexec test in Gitlab CI. This is documented at "22.7.3. Runtime
tests and Gitlab CI"
in https://buildroot.org/downloads/manual/manual.html.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot