Re: [PATCH v6 08/12] efi_loader: Disable ANSI output for tests

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

On Tue, Oct 01, 2024 at 08:49:26AM +0100, Peter Robinson wrote:
> On Tue, 1 Oct 2024 at 01:42, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Oct 01, 2024 at 01:38:56AM +0200, Heinrich Schuchardt wrote:
> > > On 26.09.24 23:59, Simon Glass wrote:
> > > > We don't want ANSI characters written in tests since it is a pain to
> > > > check the output with ut_assert_nextline() et al.
> > > >
> > > > Provide a way to tests to request that ANSI characters not be sent.
> > > >
> > > > Add a proper function comment while we are here, to encourage others.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > Please, consider prior review before resubmitting patches.
> > >
> > > As responded to all prior submissions:
> > >
> > > We want to test the code running on actual machines.
> > > We don't want to have sandbox code everywhere.
> > >
> > > I cannot see any test that is not passing due to the current behavior.
> >
> > The pytests for the EFI selftests are unreliable for me, on Raspberry Pi
> > 3, more often in 32bit mode than 64bit mode, but I feel like I see it
> > there too. And when they fail, the console log is full of ANSI escape
> > sequences. Is this specific test a test you run regularly on real
> > hardware?
> 
> Is it possible there's a bug in the RPi support somewhere that's
> causing these issues that is triggered more easily with the ASCI
> codes?

I don't think so, in that I thought I saw it on other platforms as well,
but I don't have the logs anymore. I'll see if I can trigger a failure
again.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]