public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Mittal, Anuj" <anuj.mittal@intel.com>
To: "raj.khem@gmail.com" <raj.khem@gmail.com>
Cc: "richard.purdie@linuxfoundation.org"
	<richard.purdie@linuxfoundation.org>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>,
	"steve@sakoman.com" <steve@sakoman.com>,
	"ross.burton@arm.com" <ross.burton@arm.com>,
	"randy.macleod@windriver.com" <randy.macleod@windriver.com>,
	"Sundeep.Kokkonda@windriver.com" <Sundeep.Kokkonda@windriver.com>
Subject: Re: [OE-core] Toolchain test results
Date: Thu, 27 Jul 2023 06:05:23 +0000	[thread overview]
Message-ID: <701b30f35e61a448331e7e29954d555f4b9abbd2.camel@intel.com> (raw)
In-Reply-To: <177557ED3E322BBA.21334@lists.openembedded.org>

On Wed, 2023-07-26 at 06:45 +0000, Anuj Mittal wrote:
> On Tue, 2023-07-25 at 23:29 -0700, Khem Raj wrote:
> > On Tue, Jul 25, 2023 at 11:00 PM Anuj Mittal
> > <anuj.mittal@intel.com>
> > wrote:
> > > 
> > > On Thu, 2023-07-20 at 12:26 +0100, Richard Purdie wrote:
> > > > On Tue, 2023-07-18 at 10:14 +0100, Richard Purdie via
> > > > lists.openembedded.org wrote:
> > > > > qemuarm has ~350 failures
> > > > > qemuarm64 has ~350 failures
> > > > > qemux86-64 has ~4000 (3900 in glibc)
> > > > > qemux86 has ~4000 (3500 in glibc)
> > > > > qemuppc has ~600 failures
> > > > > qemumips64 has ~5000 failures (all over)
> > > > > qemumips has ~1600 failures
> > > > > 
> > > > > Anuj: Can Intel look into the glibc test failures on x86?
> > > > 
> > > > I realised the glibc issues were due to the network being
> > > > disabled
> > > > for
> > > > the tests and have sent a patch to fix that. That reduces the
> > > > failures
> > > > from ~3900 to ~330. We should really try and reduce that
> > > > further
> > > > but
> > > > it
> > > > is a start!
> > > > 
> > > 
> > > A lot of locale/iconv tests seemed to be failing when calling
> > > write
> > > with large buffers/files over NFS. Some of others were triggering
> > > OOM.
> > > 
> > > I ran the tests again after making a few changes:
> > > 
> > > https://autobuilder.yocto.io/pub/non-release/20230726-11/testresults/qemux86-64-tc/
> > > 
> > > After switching NFS mount to TCP and increasing the memory
> > > available to
> > > 1024, the number of tests failed came down to 69.
> > > 
> > 
> > This is a nice, thanks for doing it. I looked quickly at your
> > results
> > especially glibc part
> > and it seems some of remaining failures are in nss module. I could
> > not
> > see detail logs
> > why those tests were failing but few things to check is if we
> > install
> 
> All the nss tests are failing here:
> 
> https://github.com/bminor/glibc/blob/master/support/test-container.c#L842
> 

I took a look at this and these are failing because of two
reasons. We're looking at the wrong path when creating that file
because of OBJDIR_PATH we set here:

https://git.yoctoproject.org/poky/tree/meta/recipes-core/glibc/glibc/0022-Avoid-hardcoded-build-time-paths-in-the-output-binar.patch

That path is not correct for glibc-testsuite.

Next, the test tries to acquire a lock to a file on NFS which times out
because the user space server we use doesn't support file locking with
NLM.

After reverting this patch for testing and disabling locking, all the
tests that need the test container and some others pass:

https://autobuilder.yocto.io/pub/non-release/20230727-9/testresults/qemux86-64-tc/

glibc            | 5016         | 40       | 144         | -

Thanks,

Anuj

  parent reply	other threads:[~2023-07-27  6:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1772EB68FCA90E64.1400@lists.openembedded.org>
2023-07-20 11:26 ` [OE-core] Toolchain test results Richard Purdie
2023-07-26  6:00   ` Mittal, Anuj
2023-07-26  6:29     ` Khem Raj
2023-07-26  6:45       ` Mittal, Anuj
     [not found]       ` <177557ED3E322BBA.21334@lists.openembedded.org>
2023-07-27  6:05         ` Mittal, Anuj [this message]
2023-07-26  9:17     ` Richard Purdie

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=701b30f35e61a448331e7e29954d555f4b9abbd2.camel@intel.com \
    --to=anuj.mittal@intel.com \
    --cc=Sundeep.Kokkonda@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=randy.macleod@windriver.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=ross.burton@arm.com \
    --cc=steve@sakoman.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox