> -----Original Message----- > From: Jan Kiszka <jan.kis...@siemens.com> > Sent: Montag, 13. Juli 2020 19:52 > To: Lange Norbert <norbert.la...@andritz.com>; Xenomai > (xenomai@xenomai.org) <xenomai@xenomai.org> > Subject: Re: xenomai.supported_cpus not working as intended? > > NON-ANDRITZ SOURCE: BE CAUTIOUS WITH CONTENT, LINKS OR > ATTACHMENTS. > > > On 13.07.20 15:37, Lange Norbert via Xenomai wrote: > > Hello, > > > > 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[575] 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?
I guess clocktest is not really RTnet. Or would I need a kernel with no traces of RTnet? > > cpus_supported is one of those "would be nice but usually broken when > needed" feature because we do not consistently test it. I got repeatedly told, locking Linux to some cores and RT to others is a good idea. Last time it was a MMC driver that ran into a timeout as it got preempted ( = no IO on the rootfs anymore). Seems pretty much needed instead of an optional goodie to me. I can bind Linux to Core0, I can bind my RT task to other cores, but RT drivers IRQS and rtnet stack still remains there. Norbert ________________________________ This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You ________________________________
