On Sun, Oct 1, 2023 at 7:49 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Sun, 2023-10-01 at 11:13 +0100, Richard Purdie wrote:
> > On Fri, 2023-09-29 at 16:04 -0400, bruce.ashfi...@gmail.com wrote:
> > > Given where we are in the release cycle, this clearly is NOT a typical
> > > consolidated pull request.
> > >
> > > I've done what normally takes about three weeks in about 4 days.
> > >
> > > With 6.4 going EOL before expected upstream, it really isn't a suitable
> > > reference kernel for the release.
> > >
> > > So we've decided to take on the task of getting 6.5 ready and
> available,
> > > and at the same time moving the -dev kernel to v6.6. The -dev kernel
> > > testing for 6.5 was critical for this, since I already knew the core
> > > was sane.
> > >
> > > Also we've never shipped purposely mismatched libc-headers in the
> release,
> > > so I also took the leap to update the libc-headers to match.
> > >
> > > I've already sent fixes to meta-oe, and there's a btrfs update in this
> > > series to fix breakage that I found in the tightly coupled packages.
> > >
> > > I've built and booted core-image-kernel-dev, core-image-minimal,
> core-image-sato
> > > for both glibc and musl for all the supported architectures.
> > > There will be some things that break regardless, but this needs the
> > > better coverage of the AB.
> > >
> > > If this causes too much problems, our choices are to ship 6.4 EOLd, or
> > > fall all the way back to 6.1.
> > >
> > > I'll remove 6.4 from master once we've figured out the fallout from
> > > this kernel, and which direction we are going.
> >
> > I've merged this series which seemed to work fine. Given the time
> > constraints, I thought I'd throw some 6.5 testing at the autobuilder.
> > It ran into two issues. One was cryptodev, I have a patch for that in
> > master-next. The other were entropy boot failures on arm kvm:
> >
> >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/5512/steps/12/logs/stdio
> >
> > [    0.796831] Key type id_resolver registered
> > [    0.797581] Key type id_legacy registered
> > [    0.798724] Key type cifs.idmap registered
> > [    0.808070] jitterentropy: Initialization failed with host not
> compliant with requirements: 9
> > [    0.809690] xor: measuring software checksum speed
> > [    0.811307]    8regs           : 12333 MB/sec
> > [    0.812862]    32regs          : 12322 MB/sec
> > [    0.814885]    arm64_neon      :  7851 MB/sec
> > [    0.815626] xor: using function: 8regs (12333 MB/sec)
> >
> >
> > -----------------------
> > Central error: [    0.808070] jitterentropy: Initialization failed with
> host not compliant with requirements: 9
> > ***********************
> >
> > I did find this in google:
> >
> >
> https://lore.kernel.org/linux-arm-kernel/68c6b70a-8d6c-08b5-46ce-243607479...@i2se.com/T/
> >
> > which does bisect to a change.
> >
> > I'll rerun the autobuilder testing with the cryptodev patch and see if
> > anything else transpires.
>
> The LTP on arm run failed:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/96/builds/5406
>
> which diving into the logs shows it went OOM and keeled over badly:
>
>
> https://autobuilder.yocto.io/pub/failed-builds-data/qemu_boot_log.20231001101358


I also had to up the memory on some of my ARM target testing. On target
builds were failing in strange ways until I went to 512 or 1G of memory.

But I thought that could have just been my setup.


>
> meta-virtualization doesn't like something:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/2295
>
>
There's a Xen uprev in the works, but obviously this one is something
that I'll eventually sort out.



> The arm ptest failures above are unsurprisingly still around:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/5513
>
> There may or may not be failing strace ptests on x86:
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/5694/steps/13/logs/stdio


strace can be a problem at times. I'll have a look at that first thing
monday or
late tonight, if anyone else solves it .. let me know.

Hopefully some of our ARM colleagues can help us out with the other
issues, otherwise, I will start looking at them Monday.

Bruce



>
>
> but we didn't get the world build failures from cryptodev.
>
> Cheers,
>
> Richard
>
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188487): 
https://lists.openembedded.org/g/openembedded-core/message/188487
Mute This Topic: https://lists.openembedded.org/mt/101665418/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to