[Xenomai] rt_task_bind returns -EINVAL when not using --enable-smp
g.moro at qmul.ac.uk
Sat Jun 10 21:36:19 CEST 2017
re-upping this old one just to say that on the newer kernel I have (Xenomai 3.0.5 here on kernel 4.4.68-ti-xenomai-r106 ) I cannot reproduce this one (with or without smp I get the result I reported in the new thread I just started).
From: Philippe Gerum <rpm at xenomai.org>
Sent: 16 May 2017 10:56
To: Giulio Moro; xenomai at xenomai.org
Subject: Re: [Xenomai] rt_task_bind returns -EINVAL when not using --enable-smp
On 05/15/2017 12:04 PM, Giulio Moro wrote:
> I have a 4.4.61 kernel with Xenomai 3.0.4 on am335x (BeagleBone Black) compiled with
> # CONFIG_SMP is not set
> (see XENO flags at the bottom of the email)
> When I compile the user-space support with
> /root/xenomai/configure --with-core=cobalt --enable-smp --enable-pshared
> my program (which uses the Alchemy API) works fine
> But when I do it with
> /root/xenomai/configure --with-core=cobalt --enable-pshared
> , then calls to rt_task_bind or rt_task_create return -EINVAL.
I can't reproduce this issue. You may want to check that your
application is compatible with your kernel setup by looking at the
output of <your-app> --dump-config.
# latency --dump-config
based on Xenomai/cobalt v3.0.4 -- #90a7ab2 (2017-05-16 11:12:57 +0200)
CONFIG_XENO_BUILD_ARGS=" '--host=arm-linux-gnueabihf' '--prefix=/usr'
'--disable-smp' '--disable-tls' '--disable-debug'
'--disable-valgrind-client' '--with-core=cobalt' '--enable-pshared'
> Given that SMP is not enabled in the kernel, I would expect the latter to be the correct one and possibly the former to fail.
Running a SMP-capable application on a UP kernel is a non-issue, this
just means that the application code is going to emit memory barriers
uselessly in some cases. The opposite configuration is a problem though,
which the cobalt core detects, i.e.
0"000.000| BUG in __xenomai_init(): [main] running non-SMP libraries
on SMP kernel?
build with --enable-smp or disable check with --no-sanity
> Note that /usr/xenomai/bin/xeno-test and /usr/xenomai/bin/latency work ok in both cases.
You may want to check with demo/altency, which is the strict equivalent
of the latency test written with the legacy alchemy API.
More information about the Xenomai