On Thu, 2026-05-28 at 09:25 -0400, Bruce Ashfield wrote: > > > On Thu, May 28, 2026 at 9:00 AM Richard Purdie > <[email protected]> wrote: > > Hi Bruce, > > > > On Wed, 2026-05-27 at 22:37 -0400, [email protected] wrote: > > > Here's the latest -stable bumps for OEcore and yocto-bsps (again, > > > let me know if the combined pull causes issues). > > > > > > I've also moved the dev kernel to v7.1 and fixed lttng-modules > > > along the way. Hopefully a new point release will be available soon > > > and we can quickly drop the backported patches. > > > > > > Also note that since ross removed the CVE exclusions .inc file in > > > a patch (which I think is still pending), I haven't updated the > > > exclusions for the kernel in this series. > > > > Thanks for these. I put them in for testing and there are two weird > > failures: > > > > qemuarm64 musl python3 ptest: > > > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/109/builds/460 > > > > which leads to: > > > > https://valkyrie.yocto.io/pub/non-release/20260528-74/testresults/qemuarm64-musl-ptest/python3.log > > > > test_tracemalloc_track_race > > (test.test_tracemalloc.TestCAPI.test_tracemalloc_track_race) ... Fatal > > Python error: Segmentation fault > > > > qemux86-64 musl libc-test ptest failure: > > > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/110/builds/444 > > > > which failed in functional_ipc_shm > > > > https://valkyrie.yocto.io/pub/non-release/20260528-74/testresults/qemux86-64-musl-ptest/libc-test.log > > > > FAIL src/functional/ipc_shm.exe [status 1] > > > > --- ptest result --- > > FAIL: functional_ipc_shm > > > > > > I'll rerun the tests, it is possible this is some weird intermittent > > issue, I just can't tell :( > > > > > ack'd. I also took another look at the changelogs and don't see anything that > looks obvious or makes > me think it isn't a race. > > test_tracemalloc_track_race segfault (qemuarm64-musl) > - v6.18.32 → .33 has 55 mm/kernel commits, including 1dcd36420af2 futex: > Drop CLONE_THREAD > requirement for private default hash alloc and several sched/fair tweaks > that affect timing > > That could nudge a race test toward a fail, if the test was flaky before. > > functional_ipc_shm (qemux86-64-musl libc-test) > - No ipc/ changes in v6.18.32 → .33. Kernel-side SysV shm code is untouched. > - A quick search found me a few hits on.libc-test's ipc_shm has what looks > like known intermittent > issues in some emulated arch + c library combox > > I can try a bisect between .32 and .33 if we get it to happen again, I'll > get setup for testing in case > it does fail again or becomes a common intermittent issue.
They didn't happen on the second build so it looks like intermittent failures and that should unblock these patches. Given the bug Yoann referenced, and the ones you've found about shm, I'm thinking we should get more strict about disabling flaky tests... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#237710): https://lists.openembedded.org/g/openembedded-core/message/237710 Mute This Topic: https://lists.openembedded.org/mt/119524504/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
