<richard.purdie@...> wrote: (╯°□°）╯︵ ┻━┻ If you're planning to take the day off don't worry about investigating these. I'll take a look at the patches again on

Hi Paul, Thanks for these. Unfortunately I think there is still a gremlin somewhere as this was included in an autobuilder test build that is showing as

Hello 민재, As discussed last week, you are on SWAT duty this week, could you confirm you'll be able to work on the topic? I hope you moved without any issue. Regards, -- Alexandre Belloni,

Today's failure for analysis is a qemuarm failure where all the test images  failed at the same time: https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/3493 We have's Randy+team's

Hi, Ah sorry, I forgot to send it. It is up to date with what was triaged last week: https://docs.google.com/spreadsheets/d/1bviDvW1SRwflofKLx9SwPUTWE3sBkvL3eb1PKnmZJcM/edit?usp=sharing This is

Hi Alexandre, Any update on the list/spreadsheet? Tony is getting going on valgrind and he'll start with:    https://bugzilla.yoctoproject.org/show_bug.cgi?id=14294    [Bug 14294] valgrind

The ubuntu2004-arm-1 worker has been unstable in the past and we reduced the number of simultaneous builds from 3 to 1 to see if that would stop the crashes. It didn't at first but now the crashes

I switched to Bruce's 5.12 patches. Unfortunately even with

<richard.purdie@...> wrote: sent. I cherry picked it from my queue and sent it individually. I'll continue testing the rest of my updates. Bruce -- - Thou shalt not follow the NULL

Thanks for the patch, I ran with it for a number of runs. I have not seen .38 break in the way master or master-next with .37 did. I've ran several and 50% of the time .37 would hang in ltp. Can we

About the time you were writing this, I'd hacked up: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=de3e2253482b6d9df1137128a9fde35dec8fd915 and put it into a build on the

<richard.purdie@...> wrote: I created the attached recipes. Built and booted on qemux86-64 with no issues. I assume you'll do the appropriate preferred version in the test branches to

Hello Jaga, Are you available for SWAT this week? I'll be looking at some of the failures today. Sure, no problem -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel

A set of SRCREVs sounds like the best plan, I think it might be worth testing to see if things improve or not. What is also odd is that in that in that same build, another qemu instance hung in

<richard.purdie@...> wrote: If you want to switch to linux-yocto-dev, it is on 5.12.x, and I have a local 5.13-rcX version of -dev. We could whip together a SRCREV recipe for it, if

We've got yet another rcu stall failure on the autobuilder: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/2123/steps/15/logs/stdio and looking at the dmesg in the qemu log: [

<richard.purdie@...> wrote: I can't think of anything specific that would cause those issues, but the Wind River guys did report some bad iommu patches that were part of 5.10.37 I've

Oddly enough,  https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1933  on centos7-ty-4 (master build) is locked up with pretty much exactly  the same issue/ps

https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1932 We have another ltp hang on the autobuilder. ps ax output: 9261 ? I 0:00 [kworker/2:0-rcu_gp] 9298 ? I

Hi All, When we encounter a hung ltp build I wanted to document what we need to do as a best practise for debugging it. What we need to do is: a) ssh to the worker where the build is hanging b)