Re: [OE-core] [PATCH 0/21] linux-yocto: combined and consolidated pull request

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Mon, Dec 22, 2025 at 10:34:14PM -0500, Bruce Ashfield via lists.openembedded.org wrote:
> On Mon, Dec 22, 2025 at 9:13 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > Hi Bruce,
> >
> > On Thu, 2025-12-18 at 15:22 -0500, bruce.ashfield@gmail.com wrote:
> > > As discussed in the weekly engineering call, I'm sending this as
> > > single series even though it crossed boundaries of the repositories.
> > >
> > > I don't have access to meta-yocto-contrib yet, so I haven't pushed
> > > the component parts to contrib branches yet, but will do that for
> > > future pull requests.
> > >
> > > I'm using this as a first run through some things I've cooked up
> > > to coordinate the patches across the repos. The formatting is my
> > > own, so apologies if it isn't clear .. and we'll see if it all
> > >
> > > Now to the series for OE-core:
> > >
> > >  - We have stable updates to 6.12
> > >  - A kern-tools fix
> > >  - Updates to 6.17
> > >  - Removal of 6.17
> > >  - Introduction of 6.18
> > >  - Bump to libc-headers to 6.18
> > >
> > > I've built and booted what I can locally, and I know that the
> > > major architectures work, and are functional with respect to
> > > core features.
> > >
> > > I have more libc-headers testing running against meta-oe and
> > > muslc, so there may be some breakage there and I'll help deal
> > > with that if it happens.
> > >
> > > The update and then removal of 6.17 is on purpose. In case any
> > > one was using it, they should get the latest tested before it
> > > starts to be removed.
> > >
> > > For meta-yocto:
> > >
> > >   - removal of any remaining 6.17 references
> > >   - introduction of 6.18
> > >
> > > The meta-yocto default changes are obviously REALLY RFC/RFT
> > > there will be issues, but I've provided them anyway to make it
> > > clear that we are going to 6.18 as the new default for all the
> > > variants.
> > >
> > > Once we get 6.18 fully green and the h/w references udpated,
> > > I'll remove 6.12 and 6.16 from master. That isn't in this series
> > > by design.
> >
> > I ran this through some testing and it isn't straight forward.
> >
> 
> Back online after a 10 hour drive!
> 
> > We need a newer strace with the newer kernel so I queued that patch
> > from Robert. That caused ptest failures so I disabled the failing bpf
> > strace ptests.
> 
> ok. I'll ignore strace and assume that bump will handle it.
> 
> >
> > ltp failed to compile so I backported a patch to fix that.
> >
> 
> ack'd
> 
> > We still have a cryptodev-module failure:
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/6/builds/2922
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/25/builds/2897
> > (all world builds I think)
> 
> I can handle this one, it'll be.a day or so, but I also haven't checked
> the  autoupdate list yet to see if this is in it. I'll check the lists before
> I start and see if anyone else has an update in flight.
> 
> >
> > and an initramfs module space problem:
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/22/builds/2931
> 
> And a config warning (easy for me to fix).'
> 
> For the space. Is it only genericarm64 that we do this test on ?  It
> could either e normal kernel size increases, or it could be all the work
> that has been done in genericarm64's config that has causes this.
> 
> If it is normal kernel, then I can have a look for something obvious,
> and then we can increase the size. If it is only genericarm64, then
> we should get Mikko's opinion on what might be options we could
> tweak to reduce the size.

This is normal. More drivers as modules, dependencies to firmware and slight
increase in kernel size hitting the limit again. I think increasing the limit
is the way to go now. I've been hitting this limit locally with 6.17 kernel too
after some more arm64 drivers are enabled.

Cheers,

-Mikko