qemuarm failure on autobuilder - analysis

Richard Purdie

Today's failure for analysis is a qemuarm failure where all the test images 
failed at the same time:


We have's Randy+team's logging for this here:


What is interesting is the load average is peaked at the point the three 
qemu-system-arm are running at 300+ compared to the usual 50-80.

What is it doing at the time? In parallel to qemuarm there appears to 

(in stage B, non-sstate, i.e. from scratch) 
building llvm, webkitgkt, kernel-devsrc, qemu, kea
building webkitgtk, piglit, cmake, kernel-devsrc, llvm, stress-ng

which is a pretty heavy workload as those are all pretty heavy targets.

I question whether cmake's rpmbuild really should be using 7g of RES 
memory (15g VIRT).

The python bitbake-worker processes at near 100% cpu are interesting, 
I suspect those are python tasks for recipes. The code is meant to 
rename the process so we can better identify it but that is a tricky
thing under linux and hints it may not be working.

Bottom line for this one suggests it was load related.