Thank you - will take care of it this morning. It’s related to the query I made to IRC yesterday. I will probably end up removing support from mainline for the recipe needing this.

It's back in shape now. Sorry for the hassle. -- Richard Elberger Principal Technologist – IoT Amazon Web Services +1 646.927.6897 +1 203.942.8039 – mobile elberger@... – email

No problem, thanks for fixing it! Cheers, Richard

Hello Chris, Would you be available next week for SWAT duty? Unfortunately, issues did pile up this week... :/ Regards, Alex -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and

I would be willing, but would appreciate any links to the process, as it'll be my first time doing it, and it's not entirely clear to me at this time. Thanks. -Chris

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

I tried to reproduce this on a Ubuntu-18.04.3 system with: Linux ala-lpggp3 5.4.0-72-generic #80~18.04.1-Ubuntu SMP Mon Apr 12 23:26:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Using

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

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

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

[Re: [swat] ltp failures on autobuilder] On 11/06/2021 (Fri 14:19) Richard Purdie wrote: For the mail archive trail, and for those not follwing the ongoing research on IRC, we are hopeful that this

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

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

Hello Ross, SWAT duty should rotate to you next week. Will you have some time to work on that? Thanks! -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

Yes, that's fine. Ross <alexandre.belloni@...> wrote:

Dropped the wider list but as I said to Richard, I wanted to confirm that this bug is really gone. I ran 100 tests overnight and it seems to be dead Jim. $ bitbake core-image-sato && \ for i in

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

<richard.purdie@...> wrote: Richard, As mentioned earlier, we do have the kernel debug fragments available (as well as a 'developer' kernel type). We can't globally enable the

Can this be keyed off of DEBUG_BUILD variable? -- Regards, Denys Dmytriyenko <denis@...> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186

I formed a new plan and set the stall detector to 3 seconds instead of  21 seconds with this hack in