01:19 <zeddii> RP: qemuarm64 yes. Since it isn't based on the versatile platform. I can pull something together for it. aufs/yaffs2 are disabled by default in our builds (I include a "fs" feature for my testing, so they are on), so I don't need to run the "leave them in, but disable them test"

01:20 <zeddii> I'm not seeing anything they would be doing to the common code paths, so I'm not convinced that we aren't hitting some sort of chance working. But am still preparing a standard/base branch with them reverted as a next test.

08:16 <kanavin> RP: I reproduced the cmake sdk fail, the offending sdk was preserved in pokybuild/

08:16 <kanavin> RP: will look into it in a bit

08:17 <RP> kanavin: thanks! I was just wondering what to do with that...

08:25 <RP> zeddii: For fun I did a "git diff v5.10/base v5.10/standard/base" and dropped the Documentation/ fs/aufs and fs/yaffs2 bits. There are bits in the result which make me think "hmm". Perhaps the issue isn't those fs as such but something in that remaining diff?

08:27 <RP> zeddii: The testing results 'feel' to me like there is something in this branch causing problems and it feels cross platform. That narrows the search nicely as if you drop the arch/ and tools/ we start to see some clearer differences to focus on?

08:28 <RP> zeddii: I would note that since we made the branch tweak, we've seen one rcu issue and it looked like a genuine load issue

08:33 <RP> zeddii: perhaps there is one of these wrappings of vm_file missing?

09:13 <RP> zeddii: the vm_file stuff shouldn't break, I'm wondering about the bitmap bits and cpumask/nodemask.h though

09:14 <RP> zeddii: in general it does looks like harmless stuff

14:48 <zeddii> RP: yah. I found the same. There is one change to arm/mm, but obviously that wouldn't hit x86, the rest are malta, some drivers, a few aufs additions to the fs structure, perf fixes, ppc, etc. I'll take an even closer look tonight and see if there are some strategic reverts to try. the only really common change is the vfat change we've had forever, but I can't see how it would be coming into play

14:48 <zeddii> either.

14:51 <zeddii> there is one in fs/proc/task_nommu.c and mm_types.h, I'll check them out later as well, but have to step away for a bit now. nothing glaringly wrong for sure.

16:30 <RP> zeddii: FWIW, with the patch applied to qemuarm64 in master-next (moving to /base), lttng-tools starts passing like qemux86-64

16:30 <RP> zeddii: there is *definitely* something in the difference between those branches which is causing a problem

17:07 <zeddii> lttng-tools of course pokes at internals more than anything, because lttng is a train wreck. but is that a test I can run locally to see the fail ?

17:07 <zeddii> I need to do a bisect, otherwise, we are flailing a bit.

19:43 <nagua> Hey everyone, I am currently facing problems with an esdk installation. It was build using kas. The yocto version is dunfell. If I now try to install it inside a debian:10 docker container everything works fine. But using an ubuntu system (or any other one) failes. Using "bitbake -S printdiff" I can see that pseudo is listed inside "SIGGEN_LOCKEDSIGS_t-x86-64-debian-10" inside the debian image and

19:43 <nagua> on ubuntu-* in the ubuntu containers. I saw a patch "uninative: Don't use single sstate for pseudo-native" making pseudo depend on the distribution of choise. So is this expected now that I cannot install the esdk on another distro than I build it?

19:52 <kanavin> RP: I wrote my cmake sdk findings in an email in oe-core

19:52 <kanavin> RP: needs a bit of collective intelligence

21:48 <RP> kanavin: nice analysis, thanks! Will see if halstead_ has any preferred way to handle this...

21:49 <kanavin> RP: I think there are a few older kernels still installed on centos8 hosts

21:50 <RP> zeddii: interesting, https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1871 doesn't show lttng-tools as timing out with the "revert" patch in master-next

21:50 <RP> zeddii: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=69c2bf22f3a3a4553b32297e3440450292d68d7c

21:50 <halstead> I'll need some time to understand and recommend a solution.

21:50 <RP> zeddii: I think this is breaking something by changing return values for that function

21:51 <RP> halstead: short version - maybe a different kernel?

21:51 <halstead> Seems likely. But which one... ;)

21:51 <RP> halstead: I will let you ponder on that. May have to pause the centos8 workers until we get this resolved :/

22:04 <RP> zeddii: hard part with the test is that it is timing out or hanging and I'm not sure which, I just know it repeatedly fails on the autobuilder

22:05 <RP> zeddii: bitbake core-image-ptest-all -c testimage is the test that the autobuilder is running, takes a while though

22:07 <RP> zeddii: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=11e7d9b5aacf5c8b131e95880d541d0d922a164c is a cut down ptest image with just lttng-tools in but I'm not quite sure it reproduces the problem or not. Mentioned as hint on what you can do for more focused testing

22:08 <RP> zeddii: also need the lttng-tools upgrade from master-next