xenomai.supported_cpus not working as intended?
jan.kiszka at siemens.com
Mon Jul 13 19:52:20 CEST 2020
On 13.07.20 15:37, Lange Norbert via Xenomai wrote:
> I am using Xenomai 3.1 and I tried once more to tie Linux to Core0, and RT to the remaining Cores.
> It seems that both Linux and Xenomai favor Core0, as rtnet-stack rtnet-rtpc seem to always run on that.
> Network drivers will process the IRQs on all cores, but realistally all are handles at Core0.
> I tries the commandline xenomai.supported_cpus=0xFFFE, but this doesn’t seem to work right.
> I get stuck Xenomai processes, and entries in dmesg (both with and without the isolcpus parameter).
> Kernel cmdline is like this: irqaffinity=0 xenomai.smi=disabled isolcpus=1-3 xenomai.supported_cpus=0xFFFE
> Running a Xenomai Process looks like this:
> # /usr/xenomai/bin/clocktest
> [ 191.759690] [Xenomai] thread clocktest switched to non-rt CPU0, aborted.
> == Testing built-in CLOCK_REALTIME (0)
> CPU ToD offset [us] ToD drift [us/s] warps max delta [us]
> --- -------------------- ---------------- ---------- --------------
> 0 0.0 0.000 0 0.0
> 1 -1450249.3 -36.240 0 0.0
> 2 -1450249.8 -36.040 0 0.0
> 3 -1450249.4 -35.292 0 0.0
> And similar stuff happens when booting, Kernel dmesg is following.
> So I don’t see how xenomai.supported_cpus can be safely used,
> It more or less works by chance for me (processes not getting stuck)
IIRC, we had troubles with starting off RTDM kernel tasks (like RTnet
uses) when supported_cpus is used. There is no good control over where a
kernel task comes up, specifically when it started by a built-in driver.
Or are you seeing issues even without RTnet in the picture?
cpus_supported is one of those "would be nice but usually broken when
needed" feature because we do not consistently test it.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
More information about the Xenomai