Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Hannes Mayer wrote: > Jan Kiszka wrote: > [...] >> PS: Out of curiosity I also checked RTAI's migration mechanism in this >> regard. It's similar except for the fact that it does the gatekeeper's >> work in the Linux scheduler's tail (i.e. after the next context switch). >> And RTAI seems it suffers from the very same race. So this is either a >> fundamental issue - or I'm fundamentally wrong. > > > Well, most of the stuff you guys talk about in this thread is still > beyond my level, but out of curiosity I ported the SEM example to > RTAI (see attached sem.c) > I couldn't come up with something similar to rt_sem_inquire and > rt_task_inquire in RTAI (in "void output(char c)")... > Anyway, unless I haven't missed something else important while > porting, the example runs flawlessly on RTAI 3.3test3 (kernel 2.6.15). > My claim on the RTAI race is based on quick code analysis and a bit outdated information about its core design. I haven't tried any code to crash it, and I guess it will take a slightly different test design to trigger the issue there. As soon as someone could follow my reasoning and confirm it (don't mind that you did not understand it, I hadn't either two days ago, this is quite heavy stuff), I will inform Paolo about this potential problem. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Jan Kiszka wrote:
[...]
PS: Out of curiosity I also checked RTAI's migration mechanism in this
regard. It's similar except for the fact that it does the gatekeeper's
work in the Linux scheduler's tail (i.e. after the next context switch).
And RTAI seems it suffers from the very same race. So this is either a
fundamental issue - or I'm fundamentally wrong.
Well, most of the stuff you guys talk about in this thread is still
beyond my level, but out of curiosity I ported the SEM example to
RTAI (see attached sem.c)
I couldn't come up with something similar to rt_sem_inquire and
rt_task_inquire in RTAI (in "void output(char c)")...
Anyway, unless I haven't missed something else important while
porting, the example runs flawlessly on RTAI 3.3test3 (kernel 2.6.15).
Best regards,
Hannes.
/* TEST_SEM.C ported to RTAI3.3*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int fd, err;
int t0end = 1;
int t1end = 1;
SEM *s, *m;
float tmax = 1.0e9;
#define CHECK(arg) check(arg, __LINE__)
int check(int r, int n)
{
if (r != 0)
fprintf(stderr, "L%d: %s.\n", n, strerror(-r));
return(r);
}
void output(char c) {
static int cnt = 0;
int n;
char buf[2];
buf[0] = c;
if (cnt == 80) {
buf[1] = '\n';
n = 2;
cnt = 0;
}
else {
n = 1;
cnt++;
}
/*
CHECK(rt_sem_inquire(&m, &seminfo));
if (seminfo.count != 0) {
RT_TASK_INFO taskinfo;
CHECK(rt_task_inquire(NULL, &taskinfo));
fprintf(stderr, "ALERT: No lock! (count=%ld) Offending task: %s\n",
seminfo.count, taskinfo.name);
}
*/
if (write(fd, buf, n) != n) {
fprintf(stderr, "File write error.\n");
CHECK( rt_sem_signal(s) );
}
}
static void *task0(void *args) {
RT_TASK *handler;
if (!(handler = rt_task_init_schmod(nam2num("T0HDLR"), 0, 0, 0, SCHED_FIFO, 0xF))) {
printf("CANNOT INIT HANDLER TASK > T0HDLR <\n");
exit(1);
}
rt_allow_nonroot_hrt();
mlockall(MCL_CURRENT | MCL_FUTURE);
rt_make_hard_real_time();
t0end = 0;
rt_task_use_fpu(handler, TASK_USE_FPU );
while ( !t0end ) {
rt_sleep((float)rand()*tmax/(float)RAND_MAX);
rt_sem_wait(m);
output('0');
CHECK( rt_sem_signal(m) );
}
rt_make_soft_real_time();
rt_task_delete(handler);
return 0;
}
static void *task1(void *args) {
RT_TASK *handler;
if (!(handler = rt_task_init_schmod(nam2num("T1HDLR"), 0, 0, 0, SCHED_FIFO, 0xF))) {
printf("CANNOT INIT HANDLER TASK > T1HDLR <\n");
exit(1);
}
rt_allow_nonroot_hrt();
mlockall(MCL_CURRENT | MCL_FUTURE);
rt_make_hard_real_time();
t1end = 0;
rt_task_use_fpu(handler, TASK_USE_FPU );
while ( !t1end ) {
rt_sleep((float)rand()*tmax/(float)RAND_MAX);
rt_sem_wait(m);
output('1');
CHECK( rt_sem_signal(m) );
}
rt_make_soft_real_time();
rt_task_delete(handler);
return 0;
}
void sighandler(int arg)
{
CHECK(rt_sem_signal(s));
}
int main(int argc, char *argv[])
{
RT_TASK *maint; //, *squaretask;
int t0, t1;
if ((fd = open("dump.txt", O_CREAT | O_TRUNC | O_WRONLY)) < 0)
fprintf(stderr, "File open error.\n");
else {
if (argc == 2) {
tmax = atof(argv[1]);
if (tmax == 0.0)
tmax = 1.0e7;
}
rt_set_oneshot_mode();
start_rt_timer(0);
m = rt_sem_init(nam2num("MSEM"), 1);
s = rt_sem_init(nam2num("SSEM"), 0);
signal(SIGINT, sighandler);
if (!(maint = rt_task_init(nam2num("MAIN"), 1, 0, 0))) {
printf("CANNOT INIT MAIN TASK > MAIN <\n");
exit(1);
}
t0 = rt_thread_create(task0, NULL, 1); // create thread
while (t0end) { // wait until thread went to hard real time
usleep(10);
}
t1 = rt_thread_create(task1, NULL, 1); // create thread
while (t1end) { // wait until thread went to hard real time
usleep(10);
}
printf("Running for %.2f seconds.\n", (float)MAXLONG/1.0e9);
rt_sem_wait(s);
signal(SIGINT, SIG_IGN);
t0end = 1;
t1end = 1;
printf("TEST ENDS\n");
CHECK( rt_thread_join(t0) );
CHECK( rt_thread_join(t1) );
CHECK(rt_sem_delete(s));
CHECK(rt_sem_delete(m));
CHECK( rt_task_delete(maint) );
close(fd);
}
return 0;
}
[Xenomai-core] Re: [BUG] racy xnshadow_harden under CONFIG_PREEMPT
@Jeroen: Did you verify that your setup also works fine withoutCONFIG_PREEMPT? Verified. Your workaround works. No more dmesg logs.
[Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Hi, well, if I'm not totally wrong, we have a design problem in the RT-thread hardening path. I dug into the crash Jeroen reported and I'm quite sure that this is the reason. So that's the bad news. The good one is that we can at least work around it by switching off CONFIG_PREEMPT for Linux (this implicitly means that it's a 2.6-only issue). @Jeroen: Did you verify that your setup also works fine without CONFIG_PREEMPT? But let's start with two assumptions my further analysis is based on: [Xenomai] o Shadow threads have only one stack, i.e. one context. If the real-time part is active (this includes it is blocked on some xnsynch object or delayed), the original Linux task must NEVER EVER be executed, even if it will immediately fall asleep again. That's because the stack is in use by the real-time part at that time. And this condition is checked in do_schedule_event() [1]. [Linux] o A Linux task which has called set_current_state() will remain in the run-queue as long as it calls schedule() on its own. This means that it can be preempted (if CONFIG_PREEMPT is set) between set_current_state() and schedule() and then even be resumed again. Only the explicit call of schedule() will trigger deactivate_task() which will in turn remove current from the run-queue. Ok, if this is true, let's have a look at xnshadow_harden(): After grabbing the gatekeeper sem and putting itself in gk->thread, a task going for RT then marks itself TASK_INTERRUPTIBLE and wakes up the gatekeeper [2]. This does not include a Linux reschedule due to the _sync version of wake_up_interruptible. What can happen now? 1) No interruption until we can called schedule() [3]. All fine as we will not be removed from the run-queue before the gatekeeper starts kicking our RT part, thus no conflict in using the thread's stack. 3) Interruption by a RT IRQ. This would just delay the path described above, even if some RT threads get executed. Once they are finished, we continue in xnshadow_harden() - given that the RT part does not trigger the following case: 3) Interruption by some Linux IRQ. This may cause other threads to become runnable as well, but the gatekeeper has the highest prio and will therefore be the next. The problem is that the rescheduling on Linux IRQ exit will PREEMPT our task in xnshadow_harden(), it will NOT remove it from the Linux run-queue. And now we are in real troubles: The gatekeeper will kick off our RT part which will take over the thread's stack. As soon as the RT domain falls asleep and Linux takes over again, it will continue our non-RT part as well! Actually, this seems to be the reason for the panic in do_schedule_event(). Without CONFIG_XENO_OPT_DEBUG and this check, we will run both parts AT THE SAME TIME now, thus violating my first assumption. The system gets fatally corrupted. Well, I would be happy if someone can prove me wrong here. The problem is that I don't see a solution because Linux does not provide an atomic wake-up + schedule-out under CONFIG_PREEMPT. I'm currently considering a hack to remove the migrating Linux thread manually from the run-queue, but this could easily break the Linux scheduler. Jan PS: Out of curiosity I also checked RTAI's migration mechanism in this regard. It's similar except for the fact that it does the gatekeeper's work in the Linux scheduler's tail (i.e. after the next context switch). And RTAI seems it suffers from the very same race. So this is either a fundamental issue - or I'm fundamentally wrong. [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#L1573 [2]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#L461 [3]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#L481 signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Problems generating vxworks/koan in two step: ccand link
- Original Message - From: "Niklaus Giger" <[EMAIL PROTECTED]> To: "Gilles Chanteperdrix" <[EMAIL PROTECTED]> Cc: "xenomai-core" Sent: Friday, January 20, 2006 10:43 PM Subject: Re: [Xenomai-core] Problems generating vxworks/koan in two step: ccand link Am Donnerstag, 19. Januar 2006 23:15 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: > ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks > -lnative -e __xeno_skin_init > /home/hcu/project/bb/3_1_x/work/xeno/koan.o Now I get the following > error output > ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to > 12a0 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `TaskTest':koan.c: (.text+0xbc): undefined reference to `semTake' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `CreateTask':koan.c: (.text+0x124): undefined reference to `taskSpawn' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `usrClock':koan.c: (.text+0x1c8): undefined reference to `semGive' > > :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' > > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to > `semBCreate' > > :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' > :koan.c:(.text+0x240): undefined reference to `sysClkEnable' > > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to > `taskDelete' > > What is wrong with my split? What happens if you try : cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o -u seems to be a link-time option. Thanks for the tip. This fixes my problem. Niklaus, I never tried building vxworks/koan since fusion-0.9.1 becomed xenomai what about building other vxworks sample tests ? Best regards Marco Cavallini Koan s.a.s. - Bergamo - ITALIA Embedded and Real-Time Software Engineering www.koansoftware.com|www.klinux.org
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Hannes Mayer wrote: > Jan Kiszka wrote: > [...] >> PS: Out of curiosity I also checked RTAI's migration mechanism in this >> regard. It's similar except for the fact that it does the gatekeeper's >> work in the Linux scheduler's tail (i.e. after the next context switch). >> And RTAI seems it suffers from the very same race. So this is either a >> fundamental issue - or I'm fundamentally wrong. > > > Well, most of the stuff you guys talk about in this thread is still > beyond my level, but out of curiosity I ported the SEM example to > RTAI (see attached sem.c) > I couldn't come up with something similar to rt_sem_inquire and > rt_task_inquire in RTAI (in "void output(char c)")... > Anyway, unless I haven't missed something else important while > porting, the example runs flawlessly on RTAI 3.3test3 (kernel 2.6.15). > My claim on the RTAI race is based on quick code analysis and a bit outdated information about its core design. I haven't tried any code to crash it, and I guess it will take a slightly different test design to trigger the issue there. As soon as someone could follow my reasoning and confirm it (don't mind that you did not understand it, I hadn't either two days ago, this is quite heavy stuff), I will inform Paolo about this potential problem. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Jan Kiszka wrote:
[...]
PS: Out of curiosity I also checked RTAI's migration mechanism in this
regard. It's similar except for the fact that it does the gatekeeper's
work in the Linux scheduler's tail (i.e. after the next context switch).
And RTAI seems it suffers from the very same race. So this is either a
fundamental issue - or I'm fundamentally wrong.
Well, most of the stuff you guys talk about in this thread is still
beyond my level, but out of curiosity I ported the SEM example to
RTAI (see attached sem.c)
I couldn't come up with something similar to rt_sem_inquire and
rt_task_inquire in RTAI (in "void output(char c)")...
Anyway, unless I haven't missed something else important while
porting, the example runs flawlessly on RTAI 3.3test3 (kernel 2.6.15).
Best regards,
Hannes.
/* TEST_SEM.C ported to RTAI3.3*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int fd, err;
int t0end = 1;
int t1end = 1;
SEM *s, *m;
float tmax = 1.0e9;
#define CHECK(arg) check(arg, __LINE__)
int check(int r, int n)
{
if (r != 0)
fprintf(stderr, "L%d: %s.\n", n, strerror(-r));
return(r);
}
void output(char c) {
static int cnt = 0;
int n;
char buf[2];
buf[0] = c;
if (cnt == 80) {
buf[1] = '\n';
n = 2;
cnt = 0;
}
else {
n = 1;
cnt++;
}
/*
CHECK(rt_sem_inquire(&m, &seminfo));
if (seminfo.count != 0) {
RT_TASK_INFO taskinfo;
CHECK(rt_task_inquire(NULL, &taskinfo));
fprintf(stderr, "ALERT: No lock! (count=%ld) Offending task: %s\n",
seminfo.count, taskinfo.name);
}
*/
if (write(fd, buf, n) != n) {
fprintf(stderr, "File write error.\n");
CHECK( rt_sem_signal(s) );
}
}
static void *task0(void *args) {
RT_TASK *handler;
if (!(handler = rt_task_init_schmod(nam2num("T0HDLR"), 0, 0, 0, SCHED_FIFO, 0xF))) {
printf("CANNOT INIT HANDLER TASK > T0HDLR <\n");
exit(1);
}
rt_allow_nonroot_hrt();
mlockall(MCL_CURRENT | MCL_FUTURE);
rt_make_hard_real_time();
t0end = 0;
rt_task_use_fpu(handler, TASK_USE_FPU );
while ( !t0end ) {
rt_sleep((float)rand()*tmax/(float)RAND_MAX);
rt_sem_wait(m);
output('0');
CHECK( rt_sem_signal(m) );
}
rt_make_soft_real_time();
rt_task_delete(handler);
return 0;
}
static void *task1(void *args) {
RT_TASK *handler;
if (!(handler = rt_task_init_schmod(nam2num("T1HDLR"), 0, 0, 0, SCHED_FIFO, 0xF))) {
printf("CANNOT INIT HANDLER TASK > T1HDLR <\n");
exit(1);
}
rt_allow_nonroot_hrt();
mlockall(MCL_CURRENT | MCL_FUTURE);
rt_make_hard_real_time();
t1end = 0;
rt_task_use_fpu(handler, TASK_USE_FPU );
while ( !t1end ) {
rt_sleep((float)rand()*tmax/(float)RAND_MAX);
rt_sem_wait(m);
output('1');
CHECK( rt_sem_signal(m) );
}
rt_make_soft_real_time();
rt_task_delete(handler);
return 0;
}
void sighandler(int arg)
{
CHECK(rt_sem_signal(s));
}
int main(int argc, char *argv[])
{
RT_TASK *maint; //, *squaretask;
int t0, t1;
if ((fd = open("dump.txt", O_CREAT | O_TRUNC | O_WRONLY)) < 0)
fprintf(stderr, "File open error.\n");
else {
if (argc == 2) {
tmax = atof(argv[1]);
if (tmax == 0.0)
tmax = 1.0e7;
}
rt_set_oneshot_mode();
start_rt_timer(0);
m = rt_sem_init(nam2num("MSEM"), 1);
s = rt_sem_init(nam2num("SSEM"), 0);
signal(SIGINT, sighandler);
if (!(maint = rt_task_init(nam2num("MAIN"), 1, 0, 0))) {
printf("CANNOT INIT MAIN TASK > MAIN <\n");
exit(1);
}
t0 = rt_thread_create(task0, NULL, 1); // create thread
while (t0end) { // wait until thread went to hard real time
usleep(10);
}
t1 = rt_thread_create(task1, NULL, 1); // create thread
while (t1end) { // wait until thread went to hard real time
usleep(10);
}
printf("Running for %.2f seconds.\n", (float)MAXLONG/1.0e9);
rt_sem_wait(s);
signal(SIGINT, SIG_IGN);
t0end = 1;
t1end = 1;
printf("TEST ENDS\n");
CHECK( rt_thread_join(t0) );
CHECK( rt_thread_join(t1) );
CHECK(rt_sem_delete(s));
CHECK(rt_sem_delete(m));
CHECK( rt_task_delete(maint) );
close(fd);
}
return 0;
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [BUG] racy xnshadow_harden under CONFIG_PREEMPT
@Jeroen: Did you verify that your setup also works fine withoutCONFIG_PREEMPT? Verified. Your workaround works. No more dmesg logs. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT
Hi, well, if I'm not totally wrong, we have a design problem in the RT-thread hardening path. I dug into the crash Jeroen reported and I'm quite sure that this is the reason. So that's the bad news. The good one is that we can at least work around it by switching off CONFIG_PREEMPT for Linux (this implicitly means that it's a 2.6-only issue). @Jeroen: Did you verify that your setup also works fine without CONFIG_PREEMPT? But let's start with two assumptions my further analysis is based on: [Xenomai] o Shadow threads have only one stack, i.e. one context. If the real-time part is active (this includes it is blocked on some xnsynch object or delayed), the original Linux task must NEVER EVER be executed, even if it will immediately fall asleep again. That's because the stack is in use by the real-time part at that time. And this condition is checked in do_schedule_event() [1]. [Linux] o A Linux task which has called set_current_state() will remain in the run-queue as long as it calls schedule() on its own. This means that it can be preempted (if CONFIG_PREEMPT is set) between set_current_state() and schedule() and then even be resumed again. Only the explicit call of schedule() will trigger deactivate_task() which will in turn remove current from the run-queue. Ok, if this is true, let's have a look at xnshadow_harden(): After grabbing the gatekeeper sem and putting itself in gk->thread, a task going for RT then marks itself TASK_INTERRUPTIBLE and wakes up the gatekeeper [2]. This does not include a Linux reschedule due to the _sync version of wake_up_interruptible. What can happen now? 1) No interruption until we can called schedule() [3]. All fine as we will not be removed from the run-queue before the gatekeeper starts kicking our RT part, thus no conflict in using the thread's stack. 3) Interruption by a RT IRQ. This would just delay the path described above, even if some RT threads get executed. Once they are finished, we continue in xnshadow_harden() - given that the RT part does not trigger the following case: 3) Interruption by some Linux IRQ. This may cause other threads to become runnable as well, but the gatekeeper has the highest prio and will therefore be the next. The problem is that the rescheduling on Linux IRQ exit will PREEMPT our task in xnshadow_harden(), it will NOT remove it from the Linux run-queue. And now we are in real troubles: The gatekeeper will kick off our RT part which will take over the thread's stack. As soon as the RT domain falls asleep and Linux takes over again, it will continue our non-RT part as well! Actually, this seems to be the reason for the panic in do_schedule_event(). Without CONFIG_XENO_OPT_DEBUG and this check, we will run both parts AT THE SAME TIME now, thus violating my first assumption. The system gets fatally corrupted. Well, I would be happy if someone can prove me wrong here. The problem is that I don't see a solution because Linux does not provide an atomic wake-up + schedule-out under CONFIG_PREEMPT. I'm currently considering a hack to remove the migrating Linux thread manually from the run-queue, but this could easily break the Linux scheduler. Jan PS: Out of curiosity I also checked RTAI's migration mechanism in this regard. It's similar except for the fact that it does the gatekeeper's work in the Linux scheduler's tail (i.e. after the next context switch). And RTAI seems it suffers from the very same race. So this is either a fundamental issue - or I'm fundamentally wrong. [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#L1573 [2]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#L461 [3]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/shadow.c?v=SVN-trunk#L481 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems generating vxworks/koan in two step: ccand link
- Original Message - From: "Niklaus Giger" <[EMAIL PROTECTED]> To: "Gilles Chanteperdrix" <[EMAIL PROTECTED]> Cc: "xenomai-core" Sent: Friday, January 20, 2006 10:43 PM Subject: Re: [Xenomai-core] Problems generating vxworks/koan in two step: ccand link Am Donnerstag, 19. Januar 2006 23:15 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: > ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks > -lnative -e __xeno_skin_init > /home/hcu/project/bb/3_1_x/work/xeno/koan.o Now I get the following > error output > ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to > 12a0 > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `TaskTest':koan.c: (.text+0xbc): undefined reference to `semTake' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `CreateTask':koan.c: (.text+0x124): undefined reference to `taskSpawn' > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `usrClock':koan.c: (.text+0x1c8): undefined reference to `semGive' > > :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' > > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to > `semBCreate' > > :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' > :koan.c:(.text+0x240): undefined reference to `sysClkEnable' > > /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function > `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to > `taskDelete' > > What is wrong with my split? What happens if you try : cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o -u seems to be a link-time option. Thanks for the tip. This fixes my problem. Niklaus, I never tried building vxworks/koan since fusion-0.9.1 becomed xenomai what about building other vxworks sample tests ? Best regards Marco Cavallini Koan s.a.s. - Bergamo - ITALIA Embedded and Real-Time Software Engineering www.koansoftware.com|www.klinux.org ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
