From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
Guillaume La Roque <glaroque@baylibre.com>,
Marek Vasut <marex@denx.de>,
Mattijs Korpershoek <mkorpershoek@baylibre.com>,
Sughosh Ganu <sughosh.ganu@linaro.org>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH 0/8] efi_loader: Complete the bootflow_efi() test
Date: Sat, 18 Jan 2025 11:03:40 -0600 [thread overview]
Message-ID: <20250118170340.GZ3476@bill-the-cat> (raw)
In-Reply-To: <CAFLszThscvJzBrnSovQsrMr5ie75NVc1yUss0-c_WZLksC7Rcg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]
On Fri, Jan 17, 2025 at 08:35:42PM -0800, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 13 Jan 2025 at 13:20, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 13, 2025 at 12:01:36PM -0700, Simon Glass wrote:
[snip]
> > > > Sure. test/cmd/hash.c::dm_test_cmd_hash_md5 fails randomly, in maybe 1
> > > > out of 100 runs, via pytest, in sandbox. Not via "./u-boot -T -c 'ut
> dm
> > > > dm_test_cmd_hash_md5'" however (I stopped checking after 1000
> > > > iterations). I was iterating over "and built with clang" but I think
> it
> > > > happens with gcc too, from the actual failures in CI. And you can use
> > > > "-k ut" to limit to just what's matched there, so it's a quicker
> > > > iteration.
> > >
> > > Hmmm do you have a link? It's hard to imagine what it is, but perhaps
> > > a dependency on a previous test.
> >
> > Sure:
> > https://source.denx.de/u-boot/u-boot/-/jobs/993200#L286
> >
> > My current gut feeling is that we've got some section overlap issue
> > somewhere. And, FWIW, if I turn off EFI_LOADER I still see it. And if
> > you use the same binary it won't always fail.
>
> The only way I think the hash command can return CMD_RET_USAGE is if there
> are not enough arguments.
>
> The only way that can happen with this code:
>
> ut_assertok(run_command("hash md5 $loadaddr 0", 0));
>
> is if loadaddr is undefined.
>
> But (like you, I suspect) I cannot find how that could be.
>
> In fact, I can't even build with clang:
>
> $ buildman -O clang-17 --bo sandbox -w -o /tmp/b/sandbox-clang
> Building current source for 1 boards (1 thread, 32 jobs per thread)
> sandbox: + sandbox
> +/usr/bin/llvm-ar: error: arch/sandbox/cpu/built-in.o: Opaque pointers are
> only supported in -opaque-pointers mode (Producer: 'LLVM17.0.6' Reader:
> 'LLVM 14.0.0')
> +make[2]: *** [scripts/Makefile.build:333: arch/sandbox/cpu/built-in.o]
> Error 1
> +make[1]: *** [Makefile:1906: arch/sandbox/cpu] Error 2
> +make: *** [Makefile:177: sub-make] Error 2
> 0 0 1 /1 sandbox
This command works fine for me in the CI container, so I don't know
what's going on with your local installation. I've also seen CI fail
enough times now with just regular sandbox that I don't _think_ it's a
compiler specific issue. Thanks for looking in to this more!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2025-01-18 17:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 14:47 [PATCH 0/8] efi_loader: Complete the bootflow_efi() test Simon Glass
2025-01-06 14:47 ` [PATCH 1/8] sandbox: Make USB controller as having active DMA Simon Glass
2025-01-06 14:47 ` [PATCH 2/8] efi_loader: Fix display of addresses in log Simon Glass
2025-01-07 13:37 ` Ilias Apalodimas
2025-01-07 13:57 ` Simon Glass
2025-01-08 7:12 ` Ilias Apalodimas
2025-01-08 17:03 ` Simon Glass
2025-01-06 14:47 ` [PATCH 3/8] efi_loader: Return the memory map in pointer format Simon Glass
2025-01-06 14:47 ` [PATCH 4/8] efi_loader: Correct bounce-buffer setup Simon Glass
2025-01-17 10:33 ` Ilias Apalodimas
2025-01-18 4:35 ` Simon Glass
2025-01-06 14:47 ` [PATCH 5/8] efi_loader: Check memory allocations in bootflow_efi test() Simon Glass
2025-01-06 14:47 ` [PATCH 6/8] efi_loader: Update testapp to get memory map correctly Simon Glass
2025-01-06 14:47 ` [PATCH 7/8] efi_loader: Check that the bootflow is not removed by app Simon Glass
2025-01-06 14:47 ` [PATCH 8/8] efi_loader: Test that active-DMA devices are removed Simon Glass
2025-01-06 17:00 ` [PATCH 0/8] efi_loader: Complete the bootflow_efi() test Heinrich Schuchardt
2025-01-07 12:15 ` Simon Glass
2025-01-07 13:11 ` Heinrich Schuchardt
2025-01-07 13:57 ` Simon Glass
2025-01-07 15:11 ` Tom Rini
2025-01-07 15:47 ` Heinrich Schuchardt
2025-01-08 13:39 ` Caleb Connolly
2025-01-08 17:02 ` Simon Glass
2025-01-08 17:02 ` Simon Glass
2025-01-08 19:14 ` Tom Rini
2025-01-09 15:02 ` Simon Glass
2025-01-09 16:51 ` Tom Rini
2025-01-10 13:40 ` Simon Glass
2025-01-10 16:48 ` Tom Rini
2025-01-13 19:01 ` Simon Glass
2025-01-13 20:20 ` Tom Rini
2025-01-18 4:35 ` Simon Glass
2025-01-18 17:03 ` Tom Rini [this message]
2025-01-18 17:15 ` Tom Rini
2025-01-31 0:10 ` Simon Glass
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=20250118170340.GZ3476@bill-the-cat \
--to=trini@konsulko.com \
--cc=glaroque@baylibre.com \
--cc=ilias.apalodimas@linaro.org \
--cc=marex@denx.de \
--cc=mkorpershoek@baylibre.com \
--cc=sjg@chromium.org \
--cc=sughosh.ganu@linaro.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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.