On Fri, 2021-08-27 at 10:31 -0400, Lennart Sorensen wrote: > On Fri, Aug 27, 2021 at 02:15:29PM +0200, Jan Kiszka via Xenomai wrote: > > On 27.08.21 13:39, Bezdeka, Florian (T RDA IOT SES-DE) wrote: > > > Wow, once coredumpctl was installed I got: > > > > > > Stack trace of thread 312: > > > #0 0x00000000b6f50daa _Unwind_VRS_Pop (libgcc_s.so.1) > > > > > > Compiler issue? I'm currently using > > > gcc version 10.2.1 20210110 (Debian 10.2.1-6) > > > > > > > Wait: You have a Debian 10 where (gcc is gcc-8), but for this test you > > built autotune (only that?) with gcc-10? > > Debian 11 uses gcc 10.2.1. The version says "Debian 10.2.1-6) meaning > gcc version is debian package version 10.2.1-6. It would certainly be > Debian 11. >
There is no mix between Debian 10 and 11. It's 11. Always. I updated xenomai-images locally to be based on Debian 11 already. That's were gcc 10 comes into the game. I was able to narrow this problem down to a forwarded directory from the host to the qemu guest. For performance reasons I cross-compiled all Xenomai components on the host and forwared it into the guest. That worked fine up to now, but seems to have this side effect. (The segfault happens whenever I get over the "kernel gravity stage". See below.) One problem remaining: 99% of autotune runs are failing in the "kernel gravity" stage with "Resource temporarily unavailable". That can be seen in CI runs as well. It does not matter if ipipe or dovetail is running in the kernel. Limiting the number of CPUs of the qemu guest to "1" fixes this problem. In multi-CPU setups dmesg complains about an early shot: [ 92.800781] [Xenomai] autotune(irqhand) started [ 102.499494] [Xenomai] autotune(kthread) started [ 108.623898] [Xenomai] autotune(kthread) failed with early shot (827251 ns) [ 108.646795] [Xenomai] autotune finished [0i/5000k/5000u] Any ideas?
