All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Randy MacLeod <randy.macleod@windriver.com>,
	Sakib Sajal <sakib.sajal@windriver.com>
Cc: Trevor Gamblin <trevor.gamblin@windriver.com>,
	Steve Sakoman <steve@sakoman.com>,
	OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Autobuilder data collection for intermittent bugs
Date: Mon, 05 Apr 2021 15:49:02 +0100	[thread overview]
Message-ID: <e2274153af85315f9a45eea15a75e758a21029a1.camel@linuxfoundation.org> (raw)
In-Reply-To: <e3306564-a457-4735-1ad2-0d06a484c8f9@windriver.com>

On Sun, 2021-04-04 at 15:56 -0400, Randy MacLeod wrote:
> > 
> > 
> > Rather than messing with the main index which is "production", could you just create
> > your own for now for testing? :)
> 
> Yes, we've figured all that out, thanks.
> We'll send you a patch once we've completed testing on our instance of
> the YP AB, early this week.
> 
> > 
> > FWIW I added tmpfs testing for qemu images into master-next (needs ab-helper
> > master-next too) so it will be interesting to compare builds running with that
> > with the previous build bug trends.
> 
> Any conclusions so far?

I think it helps make the runtime testing more consistent but we are seeing 
a number of "qemu didn't start in 120s" messages instead. That is probably
more desirable than random runtime failures in qemu.

We have still seen one valgrind ptest failure with the tmpfs patch too so it
doesn't remove all of them.

It also won't fix the bitbake server starting timeout problem.

I'm leaning to merging it.

I did note that in the 120s qemu timeout, we did get a list of other
processes that were running:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1973

and it shows webkit being built. Would be interesting to correlate against
other failures, see what the pattern of running tasks is.

Cheers,

Richard





      reply	other threads:[~2021-04-05 14:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 22:11 Autobuilder data collection for intermittent bugs Sakib Sajal
2021-03-25 22:23 ` Richard Purdie
2021-03-26  0:00   ` Randy MacLeod
2021-03-26 17:50     ` Richard Purdie
2021-03-31 21:45       ` Sakib Sajal
2021-03-31 22:01         ` Richard Purdie
2021-04-04 19:56           ` [OE-core] " Randy MacLeod
2021-04-05 14:49             ` Richard Purdie [this message]

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=e2274153af85315f9a45eea15a75e758a21029a1.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=randy.macleod@windriver.com \
    --cc=sakib.sajal@windriver.com \
    --cc=steve@sakoman.com \
    --cc=trevor.gamblin@windriver.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 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.