I have some good news. Now that we have merged the rcu stall crash fix: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1f802cdf857475eefb9f3ae5032a6f1ce3e01d97 I think that the cause of some of

I realised there was a potential lock issue in the rcu stall code in the kernel. In looking into it with Paul we found that upstream have a fix queued for the same issue: https://git.kernel.org/pub/sc

I formed a new plan and set the stall detector to 3 seconds instead of 21 seconds with this hack in master-next: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=71b6bc157d39e09e8f76

We have info all over the place relating to our "rcu stall" issue on the autobuilder. This is an attempt to document what we know and what we don't. We see builds fail periodically where there is an "

As a note for swat, I filed 14438 for: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1484 since I could see why it failed. Not sure why swatbot has failed but the web interface isn

Awesome work in tracking that down, much appreciated, thanks! Curious what upstream will make of it now... Cheers, Richard

Isolated down to CONFIG_SCHED_DEBUG=y being the line which somehow "fixes" the crash. I can enable all the above apart from that and we can reproduce it. Also, I changed gatesgarth to use qemu 5.2.0 c

also: IMAGE_CLASSES += "testimage" QEMU_USE_KVM_qemux86-64 = "True" Good news (for me) is that Randy and Paul can now reproduce this with the above additional key pieces of config. We have confirmed t

It became clear there is also an: IMAGE_CLASSES += "testimage" but the INHERIT people are using shouldn't make any real difference to the test. I've never seen that hrtimer message... but I do see the

Noting down what we know about the ltp issue: We've seen intermittent issues on the autobuilder where some ltp tests fail or hang. I've been trying to figure out how to reproduce the issue and narrow

No problem, thanks for fixing it! Cheers, Richard

Hi Richard, https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/73 showed up in overnight testing with an issue in meta-aws. Cheers, Richard

Not sure. We have seen some builds fail but I haven't dived into properly get down to the real cause. We run many more 64 builds than plain x86. They're happening regularly enough to be really annoyin

Also, a hung qemu build, this one has been hanging for 3 days: https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1963 Top of the kernel boot log for version info: [ 0.000000] Linux ver

https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1969 died with the following kernel panic: [ 2650.301002] option changes via remount are deprecated (pid=15940 comm=mount) [ 2652.4967

Not cross posted but mentioned here for info. Seeing if the qemu devs have any ideas. Cheers, Richard

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/3538 failure during execution of dnf --help Traceback from qemu logs fro thre 5.10 kernel (full log attached): qemux86-64 login: [ 133

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 this: https://autobuilder.yoctoproject.org/typh

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 loggi

I switched to Bruce's 5.12 patches. Unfortunately even with 5.12: https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2118/steps/12/logs/stdio :( Also, https://autobuilder.yoctoproject.o