[OE-core] [PATCH 2/6] linux-yocto/4.1: bump to v4.1.29

[Bruce Ashfield]

On Wed, Aug 24, 2016 at 7:25 AM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Fri, 2016-08-19 at 10:57 -0400, Bruce Ashfield wrote:
> > On 2016-08-18 11:20 AM, Richard Purdie wrote:
> > > On Thu, 2016-08-18 at 11:16 -0400, Bruce Ashfield wrote:
> > > > On 2016-08-18 11:15 AM, Richard Purdie wrote:
> > > > > On Mon, 2016-08-15 at 14:26 -0400, Bruce Ashfield wrote:
> > > > > > Integrating the korg 4.1.29 -stable release
> > > > > >
> > > > > > Signed-off-by: Bruce Ashfield <bruce at zedd.org>
> > > > > > ---
> > > > > >  meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++--
> > > > > > -
> > > > > >  meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++--
> > > > > > -
> > > > > >  meta/recipes-kernel/linux/linux-yocto_4.1.bb      | 20
> > > > > > ++++++++++---
> > > > > > -------
> > > > > >  3 files changed, 16 insertions(+), 16 deletions(-)
> > > > >
> > > > > FWIW since the update before this one, we've seen a lot of
> > > > > instability
> > > > > in ppc:
> > > > >
> > > > > https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-
> > > > > lsb/
> > > > > builds/881/steps/Running%20Sanity%20Tests/logs/stdio
> > > > >
> > > > > basically the network seems very flaky. Doesn't happen every
> > > > > time
> > > > > but
> > > > > we are seeing a rising number of these kinds of 'random'
> > > > > failures.
> > > > > Are
> > > > > there any ppc changes or fixes which look like they're
> > > > > responsible,
> > > > > I'm
> > > > > pretty sure its something 4.1 kernel related...
> > > > >
> > > > > The update also triggered a new 'error' for amd_nb in the error
> > > > > log
> > > > > parsing which I just whitelisted, probably from some change in
> > > > > the
> > > > > configuration options enabled.
> > > >
> > > > I have a 4.1.30 update queued locally, and I'll double check to
> > > > see
> > > > what may have changed in the configuration that could explain any
> > > > new warnings or instability.
> > >
> > > Just to be clear, the amb_nd change was on qemux86* on 4.1
> > >
> > > https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64-l
> > > sb/builds/911/steps/Running%20Sanity%20Tests/logs/stdio
> > >
> > > fixed with:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26b0657b2f7875
> > > 1e60df6e695d5bc0dd703a5bc2
> >
> > I had a look at this, and I don't have a root cause for why this is
> > just popping up now. I'm trying to track down an older build, so I
> > can
> > compare the .configs.
> >
> > The kernel code, and Kconfig files themselves haven't changed in some
> > time, and the symbol in question AMD_NB is default 'y' if the
> > dependencies are met. We include cfg/amd.scc in all of the qemux86*
> > builds, so it gets enabled (as it should have before).
> >
> > I could force that option off, but the whitelist is an appropriate
> > fix,
> > since this is an interaction between qemu and the kernel, whereas the
> > files that include amd.scc are targeted at a range of platforms.
> >
> > >
> > > The ppc issue is a separate one.
> >
> > I've been blasting away on my 4.1.30 qemuppc build, and I'm not
> > seeing
> > anything yet, but I will keep trying.
>
> Its still going on even with the recent updates:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-ppc-lsb/
> builds/889/steps/Running%20Sanity%20Tests/logs/stdio
>
> Seems the network works intermittently, dropping connections...
>

Hmm.

I've had a qemuppc up and running for 3 days now, doing transfers of files
from my server, and yet my network hasn't dropped.
I'll continue trying to figure this out.

Bruce


>
> Cheers,
>
> Richard
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160824/b32014a3/attachment-0002.html>