In my last blog, I observed that running Yocto Linux builds with all 16 threads of my new AMD Ryzen 7 1700X machine would always crash. Running under VirtualBox and only using one thread always worked; but it took seven hours. Could I achieve a compromise?
In Episode 29 of the MinnowBoard Chronicles, I described how I RMA’ed my original 2017 work week 9 Ryzen 7 1700X CPU, and got a new one with a production date stamp of work week 37. Luckily, this made the segmentation faults entirely go away during my Yocto image builds. I could play Gears of War 4 for hours without troubles. But, consistently, the new system would kick me out to the login screen after about 4,000 tasks into the 6,148 tasks executed to do a Yocto QEMU build on my Linux partition using all 16 threads. So, was I back where I started?
Googling this online and finding nothing, I decided to go back and use VirtualBox like I had done in earlier episodes of the Chronicles. And this worked like a charm; but by default VirtualBox used only one thread of my 16-thread AMD CPU. Luckily, it was easy enough to adjust the number of cores up in VirtualBox’s settings. I decided to respect its recommendations to leave 8 cores available to Windows, and have 8 decided to my Ubuntu VM for the Yocto builds.
And then, firing up all eight cores for the build:
Everything looked good so far, until I stepped away for coffee. When I came back – bang! – it was back to the logon screen again!
The good news is, if I go down one core, down to seven cores, the build will complete successfully 100% of the time.
There seems to be some strange “num_cores – 1” thing going on here: if I max out the core utilization, it always fails; if I go down by one, it always succeeds. If anyone knows why this might be, please do feel free to drop me a note – it’s very strange.
Now that I’m up and running again, I can’t wait to finish a MinnowBoard Turbot Yocto image build, and begin using SourcePoint for some serious debugging.
