[Xenomai] Differents switch mode from differents Xenomai skin

[Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

Hello everyone, 
I recently ran a comparison test between Xemai native & posix skin, the goal is to see if its possible of using a full standard posix program instead of inserting some native functions. I'm not familiar with the Xenomai Posix skin so I may lack a lot of things, if you can give me some hints, I would be very grateful. 
Test run in xenomai 2.6.3 patched in linux 3.8.13. 
My program only have 1 task who use the soem library (which use rtdm) to send a message broadcast in order to detect EtherCAT slave through a real-time port RTNet. 
I have 2 test files which use native & posix skin respectively. Here some cuts of the main() function: 
Native: 
mlockall(MCL_CURRENT | MCL_FUTURE); 
rt_print_auto_init(1); 
rt_task_spawn(&rt_task_desc_1,NULL,0,98,T_JOINABLE|T_WARNSW,&mini,NULL); 
rt_task_join(&rt_task_desc_1); 
rt_task_delete(&rt_task_desc_1); 
Posix: 
mlockall(MCL_CURRENT | MCL_FUTURE); 
pthread_attr_init(&p_attr1); 
pthread_attr_setschedpolicy(&p_attr1,SCHED_FIFO); 
pthread_attr_setdetachstate(&p_attr1, PTHREAD_CREATE_JOINABLE); 
param.sched_priority = 98; 
pthread_attr_setschedparam(&p_attr1, &param); 
pthread_create( &thread1, &p_attr1, (void *) &mini, NULL); 
pthread_join(thread1, 0); 
pthread_exit(&thread1); 
pthread_attr_destroy(&p_attr1); 

in mini(): pthread_set_mode_np(0,PTHREAD_PRIMARY|PTHREAD_WARNSW); 

in which mini() is my task. 

I activated WARNSW bit to detect spurious relaxes, according to this: http://xenomai.org/2014/06/finding-spurious-relaxes/ 

The mode switch occurs at socket level, but in differents ways: 
With native: 
Mode switch (reason invoked syscall), aborting. Backtrace: 
./testcase_native[0x40152f] 
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7eff44375cb0] 
/usr/xenomai/lib/librtdm.so.1(rt_dev_socket+0x1d)[0x7eff43d5480d 

With posix: 
Critical errors: Mode switch (reason latency:received SIXCPU for unknown reason), aborting. Backtrace: 
./testcase_posix[0x401570] 
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f40ddb7acb0] 
/usr/xenomai/lib/librtdm.so.1(rt_dev_sendmsg+0x16)[0x7f40dd5598f6] 

These 2 programs use the same functions call, compiled with same flags (rtdm, native & posix mixed): 
CFLAGS += -g -O0 -ffunction-sections -DRTNET -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -I/usr/xenomai/include/posix 
LDFLAGS += -Wl,--gc-sections -Wl,--no-as-needed -Wl,@/usr/xenomai/lib/posix.wrappers -L/usr/xenomai/lib -lrtdm -lxenomai -lpthread -lrt -lpthread_rt 

The only different is the portion I mentioned above. 

I'm trying to follow this porting guide: https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/ but there are perhaps something I went wrong. 

Thank you for any helps. 

-- 
Huy Cong 

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Thu, Dec 18, 2014 at 12:30:40PM +0100, Huy Cong Vu wrote:
> Hello everyone, I recently ran a comparison test between Xemai
> native & posix skin, the goal is to see if its possible of using a
> full standard posix program instead of inserting some native
> functions. I'm not familiar with the Xenomai Posix skin so I may
> lack a lot of things, if you can give me some hints, I would be
> very grateful. Test run in xenomai 2.6.3 patched in linux 3.8.13.

You should be using xenomai latest version, which is 2.6.4, not an
older version, especially if you have not yet chosen a particular version

> My program only have 1 task who use the soem library (which use rtdm) to send a message broadcast in order to detect EtherCAT slave through a real-time port RTNet. 
> I have 2 test files which use native & posix skin respectively. Here some cuts of the main() function: 
> Native: 
> mlockall(MCL_CURRENT | MCL_FUTURE); 
> rt_print_auto_init(1); 
> rt_task_spawn(&rt_task_desc_1,NULL,0,98,T_JOINABLE|T_WARNSW,&mini,NULL); 
> rt_task_join(&rt_task_desc_1); 
> rt_task_delete(&rt_task_desc_1); 
> Posix: 
> mlockall(MCL_CURRENT | MCL_FUTURE); 
> pthread_attr_init(&p_attr1); 
> pthread_attr_setschedpolicy(&p_attr1,SCHED_FIFO); 
> pthread_attr_setdetachstate(&p_attr1, PTHREAD_CREATE_JOINABLE); 
> param.sched_priority = 98; 
> pthread_attr_setschedparam(&p_attr1, &param); 
> pthread_create( &thread1, &p_attr1, (void *) &mini, NULL); 
> pthread_join(thread1, 0); 
> pthread_exit(&thread1); 
> pthread_attr_destroy(&p_attr1); 
> 
> in mini(): pthread_set_mode_np(0,PTHREAD_PRIMARY|PTHREAD_WARNSW); 

You do not need PTHREAD_PRIMARY, a xenomai thread will always start
in primary mode, and anyway the switch to primary or secondary mode
will  happen as needed.

> 
> in which mini() is my task. 
> 
> I activated WARNSW bit to detect spurious relaxes, according to this: http://xenomai.org/2014/06/finding-spurious-relaxes/ 
> 
> The mode switch occurs at socket level, but in differents ways: 
> With native: 
> Mode switch (reason invoked syscall), aborting. Backtrace: 
> ./testcase_native[0x40152f] 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7eff44375cb0] 
> /usr/xenomai/lib/librtdm.so.1(rt_dev_socket+0x1d)[0x7eff43d5480d 

rt_dev_socket may cause a switch to secondary mode, yes, this is
perfectly normal, only sending and receiving data is guaranteed to
not cause a switch to secondary mode.

> 
> With posix: 
> Critical errors: Mode switch (reason latency:received SIXCPU for unknown reason), aborting. Backtrace: 

Unknown reason is suspicious, if you have used the sigdebug example,
you should not that there is now an additional reason for receiving
SIGXCPU.

> ./testcase_posix[0x401570] 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f40ddb7acb0] 
> /usr/xenomai/lib/librtdm.so.1(rt_dev_sendmsg+0x16)[0x7f40dd5598f6] 
> 
> These 2 programs use the same functions call, compiled with same
> flags (rtdm, native & posix mixed): 

Most likely, rt_dev_sendmsg is passed a non real-time socket. You
can use either native or posix services to create and handle
sockets, but you can not mix the call. It meansa socket created with
rt_dev_socket (the native service) should be passed to
rt_dev_sendmsg, whereas socket created with the posix service
(socket) can only be passed to posix services (sendmsg). Is not it
what is happening here?

> The only different is the portion I mentioned above. 

Compiling for the xenomai skin causes changes in the services called
even without changing the code. So, for instance, if you use the
"socket" service, when compiling for the native skin, it will create
a plain linux socket, whereas when compiled for the posix skin, it
will try and create an RTDM socket.

To help you more, we would need more details, such as for instance a
reduced, self-contained test case allowing us to reproduce the issue
you observe.

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Jeudi 18 Décembre 2014 15:05:29
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Thu, Dec 18, 2014 at 12:30:40PM +0100, Huy Cong Vu wrote:
>> Hello everyone, I recently ran a comparison test between Xemai
>> native & posix skin, the goal is to see if its possible of using a
>> full standard posix program instead of inserting some native
>> functions. I'm not familiar with the Xenomai Posix skin so I may
>> lack a lot of things, if you can give me some hints, I would be
>> very grateful. Test run in xenomai 2.6.3 patched in linux 3.8.13.
> 
> You should be using xenomai latest version, which is 2.6.4, not an
> older version, especially if you have not yet chosen a particular version
> 
>> My program only have 1 task who use the soem library (which use rtdm) to send a
>> message broadcast in order to detect EtherCAT slave through a real-time port
>> RTNet.
>> I have 2 test files which use native & posix skin respectively. Here some cuts
>> of the main() function:
>> Native:
>> mlockall(MCL_CURRENT | MCL_FUTURE);
>> rt_print_auto_init(1);
>> rt_task_spawn(&rt_task_desc_1,NULL,0,98,T_JOINABLE|T_WARNSW,&mini,NULL);
>> rt_task_join(&rt_task_desc_1);
>> rt_task_delete(&rt_task_desc_1);
>> Posix:
>> mlockall(MCL_CURRENT | MCL_FUTURE);
>> pthread_attr_init(&p_attr1);
>> pthread_attr_setschedpolicy(&p_attr1,SCHED_FIFO);
>> pthread_attr_setdetachstate(&p_attr1, PTHREAD_CREATE_JOINABLE);
>> param.sched_priority = 98;
>> pthread_attr_setschedparam(&p_attr1, &param);
>> pthread_create( &thread1, &p_attr1, (void *) &mini, NULL);
>> pthread_join(thread1, 0);
>> pthread_exit(&thread1);
>> pthread_attr_destroy(&p_attr1);
>> 
>> in mini(): pthread_set_mode_np(0,PTHREAD_PRIMARY|PTHREAD_WARNSW);
> 
> You do not need PTHREAD_PRIMARY, a xenomai thread will always start
> in primary mode, and anyway the switch to primary or secondary mode
> will  happen as needed.
> 
>> 
>> in which mini() is my task.
>> 
>> I activated WARNSW bit to detect spurious relaxes, according to this:
>> http://xenomai.org/2014/06/finding-spurious-relaxes/
>> 
>> The mode switch occurs at socket level, but in differents ways:
>> With native:
>> Mode switch (reason invoked syscall), aborting. Backtrace:
>> ./testcase_native[0x40152f]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7eff44375cb0]
>> /usr/xenomai/lib/librtdm.so.1(rt_dev_socket+0x1d)[0x7eff43d5480d
> 
> rt_dev_socket may cause a switch to secondary mode, yes, this is
> perfectly normal, only sending and receiving data is guaranteed to
> not cause a switch to secondary mode.
> 
>> 
>> With posix:
>> Critical errors: Mode switch (reason latency:received SIXCPU for unknown
>> reason), aborting. Backtrace:
> 
> Unknown reason is suspicious, if you have used the sigdebug example,
> you should not that there is now an additional reason for receiving
> SIGXCPU.
> 

You are right, the error I got is error 7, i.e SIGDEBUG_RESCNT_IMBALANCE, knowing that I don't use a mutex in my app, so maybe it's still an unknown issue?

>> ./testcase_posix[0x401570]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f40ddb7acb0]
>> /usr/xenomai/lib/librtdm.so.1(rt_dev_sendmsg+0x16)[0x7f40dd5598f6]
>> 
>> These 2 programs use the same functions call, compiled with same
>> flags (rtdm, native & posix mixed):
> 
> Most likely, rt_dev_sendmsg is passed a non real-time socket. You
> can use either native or posix services to create and handle
> sockets, but you can not mix the call. It meansa socket created with
> rt_dev_socket (the native service) should be passed to
> rt_dev_sendmsg, whereas socket created with the posix service
> (socket) can only be passed to posix services (sendmsg). Is not it
> what is happening here?
> 

So, does that means that my test in posix skin should not calls rt_dev_sendmsg? 


>> The only different is the portion I mentioned above.
> 
> Compiling for the xenomai skin causes changes in the services called
> even without changing the code. So, for instance, if you use the
> "socket" service, when compiling for the native skin, it will create
> a plain linux socket, whereas when compiled for the posix skin, it
> will try and create an RTDM socket.
> 

Even after removing native c & ld flags, it keeps calling this native function, which is a strange behavior, no?

> To help you more, we would need more details, such as for instance a
> reduced, self-contained test case allowing us to reproduce the issue
> you observe.
> 

I'm working on that one, will post it asap. Thanks for your help.

> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Thu, Dec 18, 2014 at 05:41:26PM +0100, Huy Cong Vu wrote:
> > Unknown reason is suspicious, if you have used the sigdebug example,
> > you should not that there is now an additional reason for receiving
> > SIGXCPU.
> > 
> 
> You are right, the error I got is error 7, i.e
> SIGDEBUG_RESCNT_IMBALANCE, knowing that I don't use a mutex in my
> app, so maybe it's still an unknown issue?

That is impossible, you can not get this error if you do not use
mutexes. Maybe the library you use uses mutexes .

> 
> >> ./testcase_posix[0x401570]
> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f40ddb7acb0]
> >> /usr/xenomai/lib/librtdm.so.1(rt_dev_sendmsg+0x16)[0x7f40dd5598f6]
> >> 
> >> These 2 programs use the same functions call, compiled with same
> >> flags (rtdm, native & posix mixed):
> > 
> > Most likely, rt_dev_sendmsg is passed a non real-time socket. You
> > can use either native or posix services to create and handle
> > sockets, but you can not mix the call. It meansa socket created with
> > rt_dev_socket (the native service) should be passed to
> > rt_dev_sendmsg, whereas socket created with the posix service
> > (socket) can only be passed to posix services (sendmsg). Is not it
> > what is happening here?
> > 
> 
> So, does that means that my test in posix skin should not calls
> rt_dev_sendmsg?

No. Once again, that means that you should not use rt_dev_sendmsg
with a socket obtained with the "socket" service, but as long as you
obtain the socket with rt_dev_socket, you can use rt_devn_sendmsg.

> 
> 
> >> The only different is the portion I mentioned above.
> > 
> > Compiling for the xenomai skin causes changes in the services called
> > even without changing the code. So, for instance, if you use the
> > "socket" service, when compiling for the native skin, it will create
> > a plain linux socket, whereas when compiled for the posix skin, it
> > will try and create an RTDM socket.
> > 
> 
> Even after removing native c & ld flags, it keeps calling this
> native function, which is a strange behavior, no?

No, the calls to native functions are explicit, there is not trick.
The trick is for the posix calls. As explained here:
https://xenomai.org/2014/08/porting-a-linux-application-to-xenomai-dual-kernel/#Under_the_hood_the_8211wrap_flag


> 
> > To help you more, we would need more details, such as for instance a
> > reduced, self-contained test case allowing us to reproduce the issue
> > you observe.
> > 
> 
> I'm working on that one, will post it asap. Thanks for your help.

Waiting for this.

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Fri, Dec 19, 2014 at 10:47:58AM +0100, Huy Cong Vu wrote:
> ----- Mail original -----
> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> > Cc: xenomai@xenomai.org
> > Envoyé: Jeudi 18 Décembre 2014 18:43:47
> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> 
> > On Thu, Dec 18, 2014 at 05:41:26PM +0100, Huy Cong Vu wrote:
> >> > Unknown reason is suspicious, if you have used the sigdebug example,
> >> > you should not that there is now an additional reason for receiving
> >> > SIGXCPU.
> >> > 
> >> 
> >> You are right, the error I got is error 7, i.e
> >> SIGDEBUG_RESCNT_IMBALANCE, knowing that I don't use a mutex in my
> >> app, so maybe it's still an unknown issue?
> > 
> > That is impossible, you can not get this error if you do not use
> > mutexes. Maybe the library you use uses mutexes .
> > 
> 
> You are right, I'm able to spot some mutexes in my library,
> however, the call which cause the mode switch is not included in
> mutex zone. I tried to disable all mutexes but the error still
> occurs.

As I said, the SIGDEBUG_RESCNT_IMBALANCE should only happen when
using a mutex. The relax upon send should be unrelated though.

> 
> >> 
> >> >> ./testcase_posix[0x401570]
> >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f40ddb7acb0]
> >> >> /usr/xenomai/lib/librtdm.so.1(rt_dev_sendmsg+0x16)[0x7f40dd5598f6]
> >> >> 
> >> >> These 2 programs use the same functions call, compiled with same
> >> >> flags (rtdm, native & posix mixed):
> >> > 
> >> > Most likely, rt_dev_sendmsg is passed a non real-time socket. You
> >> > can use either native or posix services to create and handle
> >> > sockets, but you can not mix the call. It meansa socket created with
> >> > rt_dev_socket (the native service) should be passed to
> >> > rt_dev_sendmsg, whereas socket created with the posix service
> >> > (socket) can only be passed to posix services (sendmsg). Is not it
> >> > what is happening here?
> >> > 
> >> 
> >> So, does that means that my test in posix skin should not calls
> >> rt_dev_sendmsg?
> > 
> > No. Once again, that means that you should not use rt_dev_sendmsg
> > with a socket obtained with the "socket" service, but as long as you
> > obtain the socket with rt_dev_socket, you can use rt_devn_sendmsg.
> > 
> 
> I changed the call to posix wrap function, error now occur at
> __wrap_send, I made a dig in posix/rtdm.c itself and it seems that
> mode switch come from this line:
> 
> 		ret = set_errno(XENOMAI_SKINCALL3(__pse51_rtdm_muxid,
> 						  __rtdm_sendmsg,
> 						  fd - __pse51_rtdm_fd_start,
> 						  &msg, flags));
> 
> Before that, my library wanted to send a frame to an rtnet port
> that was already setup-ed with socket service. Is there something
> wrong with the fact that I'm trying to access to rtnet port with
> posix wrapped service?

I am not sure I understand what you mean. So, I am going to try and
explain a third time what I mean.

- This works:
int fd = socket

send(fd, buffer, n);

- This works:
int fd = rd_dev_socket

rt_dev_send(fd, buffer, n);

- This DOES NOT work:

int fd = rt_dev socket

send(fd, buffer, n);

- This DOES NOT work either:

int fd = socket

rt_dev_send(fd, buffer, n);

Once again, as long as you do not send us a testcase allowing us to
reproduce the problem, it is difficult to make any progress in
understanding the issue you have.

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Envoyé: Vendredi 19 Décembre 2014 11:31:33
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Fri, Dec 19, 2014 at 10:47:58AM +0100, Huy Cong Vu wrote:
>> ----- Mail original -----
>> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> > Cc: xenomai@xenomai.org
>> > Envoyé: Jeudi 18 Décembre 2014 18:43:47
>> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> 
>> > On Thu, Dec 18, 2014 at 05:41:26PM +0100, Huy Cong Vu wrote:
>> >> > Unknown reason is suspicious, if you have used the sigdebug example,
>> >> > you should not that there is now an additional reason for receiving
>> >> > SIGXCPU.
>> >> > 
>> >> 
>> >> You are right, the error I got is error 7, i.e
>> >> SIGDEBUG_RESCNT_IMBALANCE, knowing that I don't use a mutex in my
>> >> app, so maybe it's still an unknown issue?
>> > 
>> > That is impossible, you can not get this error if you do not use
>> > mutexes. Maybe the library you use uses mutexes .
>> > 
>> 
>> You are right, I'm able to spot some mutexes in my library,
>> however, the call which cause the mode switch is not included in
>> mutex zone. I tried to disable all mutexes but the error still
>> occurs.
> 
> As I said, the SIGDEBUG_RESCNT_IMBALANCE should only happen when
> using a mutex. The relax upon send should be unrelated though.
> 
>> 
>> >> 
>> >> >> ./testcase_posix[0x401570]
>> >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f40ddb7acb0]
>> >> >> /usr/xenomai/lib/librtdm.so.1(rt_dev_sendmsg+0x16)[0x7f40dd5598f6]
>> >> >> 
>> >> >> These 2 programs use the same functions call, compiled with same
>> >> >> flags (rtdm, native & posix mixed):
>> >> > 
>> >> > Most likely, rt_dev_sendmsg is passed a non real-time socket. You
>> >> > can use either native or posix services to create and handle
>> >> > sockets, but you can not mix the call. It meansa socket created with
>> >> > rt_dev_socket (the native service) should be passed to
>> >> > rt_dev_sendmsg, whereas socket created with the posix service
>> >> > (socket) can only be passed to posix services (sendmsg). Is not it
>> >> > what is happening here?
>> >> > 
>> >> 
>> >> So, does that means that my test in posix skin should not calls
>> >> rt_dev_sendmsg?
>> > 
>> > No. Once again, that means that you should not use rt_dev_sendmsg
>> > with a socket obtained with the "socket" service, but as long as you
>> > obtain the socket with rt_dev_socket, you can use rt_devn_sendmsg.
>> > 
>> 
>> I changed the call to posix wrap function, error now occur at
>> __wrap_send, I made a dig in posix/rtdm.c itself and it seems that
>> mode switch come from this line:
>> 
>> 		ret = set_errno(XENOMAI_SKINCALL3(__pse51_rtdm_muxid,
>> 						  __rtdm_sendmsg,
>> 						  fd - __pse51_rtdm_fd_start,
>> 						  &msg, flags));
>> 
>> Before that, my library wanted to send a frame to an rtnet port
>> that was already setup-ed with socket service. Is there something
>> wrong with the fact that I'm trying to access to rtnet port with
>> posix wrapped service?
> 
> I am not sure I understand what you mean. So, I am going to try and
> explain a third time what I mean.
> 
> - This works:
> int fd = socket
> 
> send(fd, buffer, n);
> 
> - This works:
> int fd = rd_dev_socket
> 
> rt_dev_send(fd, buffer, n);
> 
> - This DOES NOT work:
> 
> int fd = rt_dev socket
> 
> send(fd, buffer, n);
> 
> - This DOES NOT work either:
> 
> int fd = socket
> 
> rt_dev_send(fd, buffer, n);
> 
> Once again, as long as you do not send us a testcase allowing us to
> reproduce the problem, it is difficult to make any progress in
> understanding the issue you have.
> 
> --
> 					    Gilles.

Hi Gilles, 

I tried to create a self-contained test case that I joined in this e-mail, it's the extraction a part of the lib I used, it's still too long but I don't know which functions I should remove so I left it like that. It is my first time making a test project so if there are anything wrong, please correct me.

It included a makefile, and my test had issue when launched on rtnet interface "rteth0", switch mode pop up at __wrap_send function.

Thanks for your help.
 

-- 
Huy Cong
Wandercraft SAS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: text/x-makefile
Size: 827 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141223/0dabbb1e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: posix_minimal.c
Type: text/x-c++src
Size: 9533 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141223/0dabbb1e/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: posix_minimal.h
Type: text/x-chdr
Size: 4734 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141223/0dabbb1e/attachment.h>

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
> void mini( void *ptr )
> {
> 
> 
> 	uint8_t b;
> 	int ret1;
> 	int idx;
> 
> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>    printf("Starting posix test\n");
> 
> 	ec_port = malloc(sizeof(ecx_portt*));
> 
> 	if (setup_nic(ec_port,"rteth0") > 0) {
> 		   idx = getindex (ec_port);
>    		/* setup datagram */
> 			b = 0x0000;
>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103, sizeof(b), &b );
>    		/* send data and wait for answer */
>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> 	}
> 	
> }

Typically, as I already explained, what you do here is wrong: you
should not arm the PTHREAD_WARNSW bit before call such as malloc or
the calls in setup_nic, which switch to secondary mode. 

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Mardi 23 Décembre 2014 17:35:35
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
>> void mini( void *ptr )
>> {
>> 
>> 
>> 	uint8_t b;
>> 	int ret1;
>> 	int idx;
>> 
>> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>>    printf("Starting posix test\n");
>> 
>> 	ec_port = malloc(sizeof(ecx_portt*));
>> 
>> 	if (setup_nic(ec_port,"rteth0") > 0) {
>> 		   idx = getindex (ec_port);
>>    		/* setup datagram */
>> 			b = 0x0000;
>>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>>    		sizeof(b), &b );
>>    		/* send data and wait for answer */
>>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> 	}
>> 	
>> }
> 
> Typically, as I already explained, what you do here is wrong: you
> should not arm the PTHREAD_WARNSW bit before call such as malloc or
> the calls in setup_nic, which switch to secondary mode.

Ok, should I call it laterly? It is just for detect mode switch reason in fact.

> 
> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
> 
> 
> ----- Mail original -----
> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> > Cc: xenomai@xenomai.org
> > Envoyé: Mardi 23 Décembre 2014 17:35:35
> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> 
> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
> >> void mini( void *ptr )
> >> {
> >> 
> >> 
> >> 	uint8_t b;
> >> 	int ret1;
> >> 	int idx;
> >> 
> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
> >>    printf("Starting posix test\n");
> >> 
> >> 	ec_port = malloc(sizeof(ecx_portt*));
> >> 
> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
> >> 		   idx = getindex (ec_port);
> >>    		/* setup datagram */
> >> 			b = 0x0000;
> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
> >>    		sizeof(b), &b );
> >>    		/* send data and wait for answer */
> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> >> 	}
> >> 	
> >> }
> > 
> > Typically, as I already explained, what you do here is wrong: you
> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
> > the calls in setup_nic, which switch to secondary mode.
> 
> Ok, should I call it laterly? It is just for detect mode switch
> reason in fact

How to use PTHREAD_WARNSW is thoroughly documented, see:
https://xenomai.org/2014/06/finding-spurious-relaxes/

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Mardi 23 Décembre 2014 17:46:59
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
>> 
>> 
>> ----- Mail original -----
>> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> > Cc: xenomai@xenomai.org
>> > Envoyé: Mardi 23 Décembre 2014 17:35:35
>> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> 
>> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
>> >> void mini( void *ptr )
>> >> {
>> >> 
>> >> 
>> >> 	uint8_t b;
>> >> 	int ret1;
>> >> 	int idx;
>> >> 
>> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >>    printf("Starting posix test\n");
>> >> 
>> >> 	ec_port = malloc(sizeof(ecx_portt*));
>> >> 
>> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
>> >> 		   idx = getindex (ec_port);
>> >>    		/* setup datagram */
>> >> 			b = 0x0000;
>> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>> >>    		sizeof(b), &b );
>> >>    		/* send data and wait for answer */
>> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> >> 	}
>> >> 	
>> >> }
>> > 
>> > Typically, as I already explained, what you do here is wrong: you
>> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
>> > the calls in setup_nic, which switch to secondary mode.
>> 
>> Ok, should I call it laterly? It is just for detect mode switch
>> reason in fact
> 
> How to use PTHREAD_WARNSW is thoroughly documented, see:
> https://xenomai.org/2014/06/finding-spurious-relaxes/
> 

So perhaps I was misunderstanding this statement?
Then, you need to enable the warn_upon_switch capability on a per-thread basis. For instance, a POSIX-based application would run this code from the thread to monitor for spurious relaxes:

    /* Ask Xenomai to warn us upon switches to secondary mode. */
    pthread_set_mode_np(0, PTHREAD_WARNSW);

Does that means that I must put the line into the thread with function calls that cause mode switch?
I thought it means that I have to put the line in the threads of my program (in my case mini() ).

> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
> 
> 
> ----- Mail original -----
> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> > Cc: xenomai@xenomai.org
> > Envoyé: Mardi 23 Décembre 2014 17:46:59
> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> 
> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
> >> 
> >> 
> >> ----- Mail original -----
> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> > Cc: xenomai@xenomai.org
> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> 
> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
> >> >> void mini( void *ptr )
> >> >> {
> >> >> 
> >> >> 
> >> >> 	uint8_t b;
> >> >> 	int ret1;
> >> >> 	int idx;
> >> >> 
> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> >>    printf("Starting posix test\n");
> >> >> 
> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
> >> >> 
> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
> >> >> 		   idx = getindex (ec_port);
> >> >>    		/* setup datagram */
> >> >> 			b = 0x0000;
> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
> >> >>    		sizeof(b), &b );
> >> >>    		/* send data and wait for answer */
> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> >> >> 	}
> >> >> 	
> >> >> }
> >> > 
> >> > Typically, as I already explained, what you do here is wrong: you
> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
> >> > the calls in setup_nic, which switch to secondary mode.
> >> 
> >> Ok, should I call it laterly? It is just for detect mode switch
> >> reason in fact
> > 
> > How to use PTHREAD_WARNSW is thoroughly documented, see:
> > https://xenomai.org/2014/06/finding-spurious-relaxes/
> > 
> 
> So perhaps I was misunderstanding this statement?
> Then, you need to enable the warn_upon_switch capability on a per-thread basis. For instance, a POSIX-based application would run this code from the thread to monitor for spurious relaxes:
> 
>     /* Ask Xenomai to warn us upon switches to secondary mode. */
>     pthread_set_mode_np(0, PTHREAD_WARNSW);
> 
> Does that means that I must put the line into the thread with function calls that cause mode switch?
> I thought it means that I have to put the line in the threads of my program (in my case mini() ).

Enabling this bit, causes every switch to secondary mode of the
thread where you enabled it to send a signal to that thread. I do
not understand what is so hard to understand about this.

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Mercredi 24 Décembre 2014 01:29:12
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
>> 
>> 
>> ----- Mail original -----
>> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> > Cc: xenomai@xenomai.org
>> > Envoyé: Mardi 23 Décembre 2014 17:46:59
>> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> 
>> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
>> >> 
>> >> 
>> >> ----- Mail original -----
>> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> > Cc: xenomai@xenomai.org
>> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
>> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> 
>> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
>> >> >> void mini( void *ptr )
>> >> >> {
>> >> >> 
>> >> >> 
>> >> >> 	uint8_t b;
>> >> >> 	int ret1;
>> >> >> 	int idx;
>> >> >> 
>> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> >>    printf("Starting posix test\n");
>> >> >> 
>> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
>> >> >> 
>> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
>> >> >> 		   idx = getindex (ec_port);
>> >> >>    		/* setup datagram */
>> >> >> 			b = 0x0000;
>> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>> >> >>    		sizeof(b), &b );
>> >> >>    		/* send data and wait for answer */
>> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> >> >> 	}
>> >> >> 	
>> >> >> }
>> >> > 
>> >> > Typically, as I already explained, what you do here is wrong: you
>> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
>> >> > the calls in setup_nic, which switch to secondary mode.
>> >> 
>> >> Ok, should I call it laterly? It is just for detect mode switch
>> >> reason in fact
>> > 
>> > How to use PTHREAD_WARNSW is thoroughly documented, see:
>> > https://xenomai.org/2014/06/finding-spurious-relaxes/
>> > 
>> 
>> So perhaps I was misunderstanding this statement?
>> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
>> For instance, a POSIX-based application would run this code from the thread to
>> monitor for spurious relaxes:
>> 
>>     /* Ask Xenomai to warn us upon switches to secondary mode. */
>>     pthread_set_mode_np(0, PTHREAD_WARNSW);
>> 
>> Does that means that I must put the line into the thread with function calls
>> that cause mode switch?
>> I thought it means that I have to put the line in the threads of my program (in
>> my case mini() ).
> 
> Enabling this bit, causes every switch to secondary mode of the
> thread where you enabled it to send a signal to that thread. I do
> not understand what is so hard to understand about this.

Ok, so I guess I didn't understand this wrongly at least.  

Suppose that I remove PTHREAD_WARNSW bit, here what I got in output: 
SOEM (Simple Open EtherCAT Master)
Simple test
Starting posix test
Mode switch (reason bad functions call while holding mutex, or other unknown issue), aborting. Backtrace:
./posix_minimal[0x401bf6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
/usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
./posix_minimal[0x4017dc]
./posix_minimal[0x4016ed]
./posix_minimal[0x4011cd]
/usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
Temps UCT limite expiré (core dumped)

It is the same output as when PTHREAD_WARNSW is active. Could you give me some hints why?

> 
> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Wed, Dec 24, 2014 at 10:30:18AM +0100, Huy Cong Vu wrote:
> 
> 
> ----- Mail original -----
> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> > Cc: xenomai@xenomai.org
> > Envoyé: Mercredi 24 Décembre 2014 01:29:12
> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> 
> > On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
> >> 
> >> 
> >> ----- Mail original -----
> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> > Cc: xenomai@xenomai.org
> >> > Envoyé: Mardi 23 Décembre 2014 17:46:59
> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> 
> >> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
> >> >> 
> >> >> 
> >> >> ----- Mail original -----
> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> >> > Cc: xenomai@xenomai.org
> >> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> >> 
> >> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
> >> >> >> void mini( void *ptr )
> >> >> >> {
> >> >> >> 
> >> >> >> 
> >> >> >> 	uint8_t b;
> >> >> >> 	int ret1;
> >> >> >> 	int idx;
> >> >> >> 
> >> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> >> >>    printf("Starting posix test\n");
> >> >> >> 
> >> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
> >> >> >> 
> >> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
> >> >> >> 		   idx = getindex (ec_port);
> >> >> >>    		/* setup datagram */
> >> >> >> 			b = 0x0000;
> >> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
> >> >> >>    		sizeof(b), &b );
> >> >> >>    		/* send data and wait for answer */
> >> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> >> >> >> 	}
> >> >> >> 	
> >> >> >> }
> >> >> > 
> >> >> > Typically, as I already explained, what you do here is wrong: you
> >> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
> >> >> > the calls in setup_nic, which switch to secondary mode.
> >> >> 
> >> >> Ok, should I call it laterly? It is just for detect mode switch
> >> >> reason in fact
> >> > 
> >> > How to use PTHREAD_WARNSW is thoroughly documented, see:
> >> > https://xenomai.org/2014/06/finding-spurious-relaxes/
> >> > 
> >> 
> >> So perhaps I was misunderstanding this statement?
> >> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
> >> For instance, a POSIX-based application would run this code from the thread to
> >> monitor for spurious relaxes:
> >> 
> >>     /* Ask Xenomai to warn us upon switches to secondary mode. */
> >>     pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> 
> >> Does that means that I must put the line into the thread with function calls
> >> that cause mode switch?
> >> I thought it means that I have to put the line in the threads of my program (in
> >> my case mini() ).
> > 
> > Enabling this bit, causes every switch to secondary mode of the
> > thread where you enabled it to send a signal to that thread. I do
> > not understand what is so hard to understand about this.
> 
> Ok, so I guess I didn't understand this wrongly at least.  
> 
> Suppose that I remove PTHREAD_WARNSW bit, here what I got in output: 
> SOEM (Simple Open EtherCAT Master)
> Simple test
> Starting posix test
> Mode switch (reason bad functions call while holding mutex, or other unknown issue), aborting. Backtrace:
> ./posix_minimal[0x401bf6]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
> /usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
> ./posix_minimal[0x4017dc]
> ./posix_minimal[0x4016ed]
> ./posix_minimal[0x4011cd]
> /usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
> Temps UCT limite expiré (core dumped)
> 
> It is the same output as when PTHREAD_WARNSW is active. Could you give me some hints why?

I already gave you some hints. I need to run the test code you sent.
But the test code you sent is wrong in the place where it enables
the PTHREAD_WARNSW bit.

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Mercredi 24 Décembre 2014 15:49:28
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Wed, Dec 24, 2014 at 10:30:18AM +0100, Huy Cong Vu wrote:
>> 
>> 
>> ----- Mail original -----
>> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> > Cc: xenomai@xenomai.org
>> > Envoyé: Mercredi 24 Décembre 2014 01:29:12
>> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> 
>> > On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
>> >> 
>> >> 
>> >> ----- Mail original -----
>> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> > Cc: xenomai@xenomai.org
>> >> > Envoyé: Mardi 23 Décembre 2014 17:46:59
>> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> 
>> >> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
>> >> >> 
>> >> >> 
>> >> >> ----- Mail original -----
>> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> >> > Cc: xenomai@xenomai.org
>> >> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
>> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> >> 
>> >> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
>> >> >> >> void mini( void *ptr )
>> >> >> >> {
>> >> >> >> 
>> >> >> >> 
>> >> >> >> 	uint8_t b;
>> >> >> >> 	int ret1;
>> >> >> >> 	int idx;
>> >> >> >> 
>> >> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> >> >>    printf("Starting posix test\n");
>> >> >> >> 
>> >> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
>> >> >> >> 
>> >> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
>> >> >> >> 		   idx = getindex (ec_port);
>> >> >> >>    		/* setup datagram */
>> >> >> >> 			b = 0x0000;
>> >> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>> >> >> >>    		sizeof(b), &b );
>> >> >> >>    		/* send data and wait for answer */
>> >> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> >> >> >> 	}
>> >> >> >> 	
>> >> >> >> }
>> >> >> > 
>> >> >> > Typically, as I already explained, what you do here is wrong: you
>> >> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
>> >> >> > the calls in setup_nic, which switch to secondary mode.
>> >> >> 
>> >> >> Ok, should I call it laterly? It is just for detect mode switch
>> >> >> reason in fact
>> >> > 
>> >> > How to use PTHREAD_WARNSW is thoroughly documented, see:
>> >> > https://xenomai.org/2014/06/finding-spurious-relaxes/
>> >> > 
>> >> 
>> >> So perhaps I was misunderstanding this statement?
>> >> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
>> >> For instance, a POSIX-based application would run this code from the thread to
>> >> monitor for spurious relaxes:
>> >> 
>> >>     /* Ask Xenomai to warn us upon switches to secondary mode. */
>> >>     pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> 
>> >> Does that means that I must put the line into the thread with function calls
>> >> that cause mode switch?
>> >> I thought it means that I have to put the line in the threads of my program (in
>> >> my case mini() ).
>> > 
>> > Enabling this bit, causes every switch to secondary mode of the
>> > thread where you enabled it to send a signal to that thread. I do
>> > not understand what is so hard to understand about this.
>> 
>> Ok, so I guess I didn't understand this wrongly at least.
>> 
>> Suppose that I remove PTHREAD_WARNSW bit, here what I got in output:
>> SOEM (Simple Open EtherCAT Master)
>> Simple test
>> Starting posix test
>> Mode switch (reason bad functions call while holding mutex, or other unknown
>> issue), aborting. Backtrace:
>> ./posix_minimal[0x401bf6]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
>> /usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
>> ./posix_minimal[0x4017dc]
>> ./posix_minimal[0x4016ed]
>> ./posix_minimal[0x4011cd]
>> /usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
>> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
>> Temps UCT limite expiré (core dumped)
>> 
>> It is the same output as when PTHREAD_WARNSW is active. Could you give me some
>> hints why?
> 
> I already gave you some hints. I need to run the test code you sent.
> But the test code you sent is wrong in the place where it enables
> the PTHREAD_WARNSW bit.

The output of: 
 void mini( void *ptr )
 {
 
 	uint8_t b;
 	int ret1;
 	int idx;

        printf("Starting posix test\n");
 
 	ec_port = malloc(sizeof(ecx_portt*));
 
 	if (setup_nic(ec_port,"rteth0") > 0) {
 		   idx = getindex (ec_port);
     		   /* setup datagram */
         	   b = 0x0000;
    	           setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
    	           sizeof(b), &b );    	
                   /* send data and wait for answer */
                   pthread_set_mode_np(0, PTHREAD_WARNSW);
                   wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
        }
}

and program without any PTHREAD_WARNSW are the same as the last post I gave you. So we can conclude that it was not setup_nic or malloc which trigger the SIGDEBUG handler. 

Then, with the native skin, I tried replace rt_task_spawn with rt_task_shadow, and this problem re-occurs. So perhaps it is not only the difference between posix & native but also the way that task is created has an impact on the mode switch.

> 
> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Mon, Jan 05, 2015 at 11:30:39AM +0100, Huy Cong Vu wrote:
> 
> 
> ----- Mail original -----
> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> > Cc: xenomai@xenomai.org
> > Envoyé: Mercredi 24 Décembre 2014 15:49:28
> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> 
> > On Wed, Dec 24, 2014 at 10:30:18AM +0100, Huy Cong Vu wrote:
> >> 
> >> 
> >> ----- Mail original -----
> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> > Cc: xenomai@xenomai.org
> >> > Envoyé: Mercredi 24 Décembre 2014 01:29:12
> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> 
> >> > On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
> >> >> 
> >> >> 
> >> >> ----- Mail original -----
> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> >> > Cc: xenomai@xenomai.org
> >> >> > Envoyé: Mardi 23 Décembre 2014 17:46:59
> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> >> 
> >> >> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
> >> >> >> 
> >> >> >> 
> >> >> >> ----- Mail original -----
> >> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> >> >> > Cc: xenomai@xenomai.org
> >> >> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
> >> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> >> >> 
> >> >> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
> >> >> >> >> void mini( void *ptr )
> >> >> >> >> {
> >> >> >> >> 
> >> >> >> >> 
> >> >> >> >> 	uint8_t b;
> >> >> >> >> 	int ret1;
> >> >> >> >> 	int idx;
> >> >> >> >> 
> >> >> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> >> >> >>    printf("Starting posix test\n");
> >> >> >> >> 
> >> >> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
> >> >> >> >> 
> >> >> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
> >> >> >> >> 		   idx = getindex (ec_port);
> >> >> >> >>    		/* setup datagram */
> >> >> >> >> 			b = 0x0000;
> >> >> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
> >> >> >> >>    		sizeof(b), &b );
> >> >> >> >>    		/* send data and wait for answer */
> >> >> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> >> >> >> >> 	}
> >> >> >> >> 	
> >> >> >> >> }
> >> >> >> > 
> >> >> >> > Typically, as I already explained, what you do here is wrong: you
> >> >> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
> >> >> >> > the calls in setup_nic, which switch to secondary mode.
> >> >> >> 
> >> >> >> Ok, should I call it laterly? It is just for detect mode switch
> >> >> >> reason in fact
> >> >> > 
> >> >> > How to use PTHREAD_WARNSW is thoroughly documented, see:
> >> >> > https://xenomai.org/2014/06/finding-spurious-relaxes/
> >> >> > 
> >> >> 
> >> >> So perhaps I was misunderstanding this statement?
> >> >> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
> >> >> For instance, a POSIX-based application would run this code from the thread to
> >> >> monitor for spurious relaxes:
> >> >> 
> >> >>     /* Ask Xenomai to warn us upon switches to secondary mode. */
> >> >>     pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> >> 
> >> >> Does that means that I must put the line into the thread with function calls
> >> >> that cause mode switch?
> >> >> I thought it means that I have to put the line in the threads of my program (in
> >> >> my case mini() ).
> >> > 
> >> > Enabling this bit, causes every switch to secondary mode of the
> >> > thread where you enabled it to send a signal to that thread. I do
> >> > not understand what is so hard to understand about this.
> >> 
> >> Ok, so I guess I didn't understand this wrongly at least.
> >> 
> >> Suppose that I remove PTHREAD_WARNSW bit, here what I got in output:
> >> SOEM (Simple Open EtherCAT Master)
> >> Simple test
> >> Starting posix test
> >> Mode switch (reason bad functions call while holding mutex, or other unknown
> >> issue), aborting. Backtrace:
> >> ./posix_minimal[0x401bf6]
> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
> >> /usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
> >> ./posix_minimal[0x4017dc]
> >> ./posix_minimal[0x4016ed]
> >> ./posix_minimal[0x4011cd]
> >> /usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
> >> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
> >> Temps UCT limite expiré (core dumped)
> >> 
> >> It is the same output as when PTHREAD_WARNSW is active. Could you give me some
> >> hints why?
> > 
> > I already gave you some hints. I need to run the test code you sent.
> > But the test code you sent is wrong in the place where it enables
> > the PTHREAD_WARNSW bit.
> 
> The output of: 
>  void mini( void *ptr )
>  {
>  
>  	uint8_t b;
>  	int ret1;
>  	int idx;
> 
>         printf("Starting posix test\n");
>  
>  	ec_port = malloc(sizeof(ecx_portt*));
>  
>  	if (setup_nic(ec_port,"rteth0") > 0) {
>  		   idx = getindex (ec_port);
>      		   /* setup datagram */
>          	   b = 0x0000;
>     	           setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>     	           sizeof(b), &b );    	
>                    /* send data and wait for answer */
>                    pthread_set_mode_np(0, PTHREAD_WARNSW);
>                    wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>         }
> }
> 
> and program without any PTHREAD_WARNSW are the same as the last post I gave you. So we can conclude that it was not setup_nic or malloc which trigger the SIGDEBUG handler. 

It makes sense for malloc not to cause a SIGDEBUG, because malloc
does not always cause a switch to secondary mode. But for setup_nic
I really have doubts. Are you sure that the thread is not running
with the SCHED_OTHER policy and this is not the cause of both
behaviours (no mode switch on secondary mode operations, because the
thread is running in secondary mode, then switch when calling a
primary mode operation because of the automatic switch back to
secondary mode due to the SCHED_OTHER policy)?

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Lundi 5 Janvier 2015 17:58:13
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Mon, Jan 05, 2015 at 11:30:39AM +0100, Huy Cong Vu wrote:
>> 
>> 
>> ----- Mail original -----
>> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> > Cc: xenomai@xenomai.org
>> > Envoyé: Mercredi 24 Décembre 2014 15:49:28
>> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> 
>> > On Wed, Dec 24, 2014 at 10:30:18AM +0100, Huy Cong Vu wrote:
>> >> 
>> >> 
>> >> ----- Mail original -----
>> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> > Cc: xenomai@xenomai.org
>> >> > Envoyé: Mercredi 24 Décembre 2014 01:29:12
>> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> 
>> >> > On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
>> >> >> 
>> >> >> 
>> >> >> ----- Mail original -----
>> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> >> > Cc: xenomai@xenomai.org
>> >> >> > Envoyé: Mardi 23 Décembre 2014 17:46:59
>> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> >> 
>> >> >> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
>> >> >> >> 
>> >> >> >> 
>> >> >> >> ----- Mail original -----
>> >> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> >> >> > Cc: xenomai@xenomai.org
>> >> >> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
>> >> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> >> >> 
>> >> >> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
>> >> >> >> >> void mini( void *ptr )
>> >> >> >> >> {
>> >> >> >> >> 
>> >> >> >> >> 
>> >> >> >> >> 	uint8_t b;
>> >> >> >> >> 	int ret1;
>> >> >> >> >> 	int idx;
>> >> >> >> >> 
>> >> >> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> >> >> >>    printf("Starting posix test\n");
>> >> >> >> >> 
>> >> >> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
>> >> >> >> >> 
>> >> >> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
>> >> >> >> >> 		   idx = getindex (ec_port);
>> >> >> >> >>    		/* setup datagram */
>> >> >> >> >> 			b = 0x0000;
>> >> >> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>> >> >> >> >>    		sizeof(b), &b );
>> >> >> >> >>    		/* send data and wait for answer */
>> >> >> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> >> >> >> >> 	}
>> >> >> >> >> 	
>> >> >> >> >> }
>> >> >> >> > 
>> >> >> >> > Typically, as I already explained, what you do here is wrong: you
>> >> >> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
>> >> >> >> > the calls in setup_nic, which switch to secondary mode.
>> >> >> >> 
>> >> >> >> Ok, should I call it laterly? It is just for detect mode switch
>> >> >> >> reason in fact
>> >> >> > 
>> >> >> > How to use PTHREAD_WARNSW is thoroughly documented, see:
>> >> >> > https://xenomai.org/2014/06/finding-spurious-relaxes/
>> >> >> > 
>> >> >> 
>> >> >> So perhaps I was misunderstanding this statement?
>> >> >> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
>> >> >> For instance, a POSIX-based application would run this code from the thread to
>> >> >> monitor for spurious relaxes:
>> >> >> 
>> >> >>     /* Ask Xenomai to warn us upon switches to secondary mode. */
>> >> >>     pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> >> 
>> >> >> Does that means that I must put the line into the thread with function calls
>> >> >> that cause mode switch?
>> >> >> I thought it means that I have to put the line in the threads of my program (in
>> >> >> my case mini() ).
>> >> > 
>> >> > Enabling this bit, causes every switch to secondary mode of the
>> >> > thread where you enabled it to send a signal to that thread. I do
>> >> > not understand what is so hard to understand about this.
>> >> 
>> >> Ok, so I guess I didn't understand this wrongly at least.
>> >> 
>> >> Suppose that I remove PTHREAD_WARNSW bit, here what I got in output:
>> >> SOEM (Simple Open EtherCAT Master)
>> >> Simple test
>> >> Starting posix test
>> >> Mode switch (reason bad functions call while holding mutex, or other unknown
>> >> issue), aborting. Backtrace:
>> >> ./posix_minimal[0x401bf6]
>> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
>> >> /usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
>> >> ./posix_minimal[0x4017dc]
>> >> ./posix_minimal[0x4016ed]
>> >> ./posix_minimal[0x4011cd]
>> >> /usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
>> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
>> >> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
>> >> Temps UCT limite expiré (core dumped)
>> >> 
>> >> It is the same output as when PTHREAD_WARNSW is active. Could you give me some
>> >> hints why?
>> > 
>> > I already gave you some hints. I need to run the test code you sent.
>> > But the test code you sent is wrong in the place where it enables
>> > the PTHREAD_WARNSW bit.
>> 
>> The output of:
>>  void mini( void *ptr )
>>  {
>>  
>>  	uint8_t b;
>>  	int ret1;
>>  	int idx;
>> 
>>         printf("Starting posix test\n");
>>  
>>  	ec_port = malloc(sizeof(ecx_portt*));
>>  
>>  	if (setup_nic(ec_port,"rteth0") > 0) {
>>  		   idx = getindex (ec_port);
>>      		   /* setup datagram */
>>          	   b = 0x0000;
>>     	           setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>>     	           sizeof(b), &b );
>>                    /* send data and wait for answer */
>>                    pthread_set_mode_np(0, PTHREAD_WARNSW);
>>                    wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>>         }
>> }
>> 
>> and program without any PTHREAD_WARNSW are the same as the last post I gave you.
>> So we can conclude that it was not setup_nic or malloc which trigger the
>> SIGDEBUG handler.
> 
> It makes sense for malloc not to cause a SIGDEBUG, because malloc
> does not always cause a switch to secondary mode. But for setup_nic
> I really have doubts. Are you sure that the thread is not running
> with the SCHED_OTHER policy and this is not the cause of both
> behaviours (no mode switch on secondary mode operations, because the
> thread is running in secondary mode, then switch when calling a
> primary mode operation because of the automatic switch back to
> secondary mode due to the SCHED_OTHER policy)?
> 

Hi Gilles, 

With my old minimal test, there were no mode switch for setup_nic with SCHED_OTHER & SCHED_FIFO. The mode switch occurs only at the __wrap_send call (err RESCNT_IMBALANCE)

But I inserted this line yesterday in main() function to setup p_attr1: 
pthread_attr_setinheritsched(&p_attr1, PTHREAD_EXPLICIT_SCHED);

With this, the behavior becomes normal, i.e:
with SCHED_FIFO, there are 1 mode switch in setup_nic when calling __wrap_socket (which is valid), and after that there are no mode switch anymore.
with SCHED_OTHER, always the same mode switch at __wrap_send.

So basiclly, now its worked, but I don't understand why the setinheritsched call can hold the mode switch in __wrap_send while all others fail? 
 
> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Gilles Chanteperdrix]

On Tue, Jan 06, 2015 at 10:09:30AM +0100, Huy Cong Vu wrote:
> 
> 
> ----- Mail original -----
> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> > Cc: xenomai@xenomai.org
> > Envoyé: Lundi 5 Janvier 2015 17:58:13
> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> 
> > On Mon, Jan 05, 2015 at 11:30:39AM +0100, Huy Cong Vu wrote:
> >> 
> >> 
> >> ----- Mail original -----
> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> > Cc: xenomai@xenomai.org
> >> > Envoyé: Mercredi 24 Décembre 2014 15:49:28
> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> 
> >> > On Wed, Dec 24, 2014 at 10:30:18AM +0100, Huy Cong Vu wrote:
> >> >> 
> >> >> 
> >> >> ----- Mail original -----
> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> >> > Cc: xenomai@xenomai.org
> >> >> > Envoyé: Mercredi 24 Décembre 2014 01:29:12
> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> >> 
> >> >> > On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
> >> >> >> 
> >> >> >> 
> >> >> >> ----- Mail original -----
> >> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> >> >> > Cc: xenomai@xenomai.org
> >> >> >> > Envoyé: Mardi 23 Décembre 2014 17:46:59
> >> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> >> >> 
> >> >> >> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
> >> >> >> >> 
> >> >> >> >> 
> >> >> >> >> ----- Mail original -----
> >> >> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> >> >> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> >> >> >> >> > Cc: xenomai@xenomai.org
> >> >> >> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
> >> >> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
> >> >> >> >> 
> >> >> >> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
> >> >> >> >> >> void mini( void *ptr )
> >> >> >> >> >> {
> >> >> >> >> >> 
> >> >> >> >> >> 
> >> >> >> >> >> 	uint8_t b;
> >> >> >> >> >> 	int ret1;
> >> >> >> >> >> 	int idx;
> >> >> >> >> >> 
> >> >> >> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> >> >> >> >>    printf("Starting posix test\n");
> >> >> >> >> >> 
> >> >> >> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
> >> >> >> >> >> 
> >> >> >> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
> >> >> >> >> >> 		   idx = getindex (ec_port);
> >> >> >> >> >>    		/* setup datagram */
> >> >> >> >> >> 			b = 0x0000;
> >> >> >> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
> >> >> >> >> >>    		sizeof(b), &b );
> >> >> >> >> >>    		/* send data and wait for answer */
> >> >> >> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> >> >> >> >> >> 	}
> >> >> >> >> >> 	
> >> >> >> >> >> }
> >> >> >> >> > 
> >> >> >> >> > Typically, as I already explained, what you do here is wrong: you
> >> >> >> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
> >> >> >> >> > the calls in setup_nic, which switch to secondary mode.
> >> >> >> >> 
> >> >> >> >> Ok, should I call it laterly? It is just for detect mode switch
> >> >> >> >> reason in fact
> >> >> >> > 
> >> >> >> > How to use PTHREAD_WARNSW is thoroughly documented, see:
> >> >> >> > https://xenomai.org/2014/06/finding-spurious-relaxes/
> >> >> >> > 
> >> >> >> 
> >> >> >> So perhaps I was misunderstanding this statement?
> >> >> >> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
> >> >> >> For instance, a POSIX-based application would run this code from the thread to
> >> >> >> monitor for spurious relaxes:
> >> >> >> 
> >> >> >>     /* Ask Xenomai to warn us upon switches to secondary mode. */
> >> >> >>     pthread_set_mode_np(0, PTHREAD_WARNSW);
> >> >> >> 
> >> >> >> Does that means that I must put the line into the thread with function calls
> >> >> >> that cause mode switch?
> >> >> >> I thought it means that I have to put the line in the threads of my program (in
> >> >> >> my case mini() ).
> >> >> > 
> >> >> > Enabling this bit, causes every switch to secondary mode of the
> >> >> > thread where you enabled it to send a signal to that thread. I do
> >> >> > not understand what is so hard to understand about this.
> >> >> 
> >> >> Ok, so I guess I didn't understand this wrongly at least.
> >> >> 
> >> >> Suppose that I remove PTHREAD_WARNSW bit, here what I got in output:
> >> >> SOEM (Simple Open EtherCAT Master)
> >> >> Simple test
> >> >> Starting posix test
> >> >> Mode switch (reason bad functions call while holding mutex, or other unknown
> >> >> issue), aborting. Backtrace:
> >> >> ./posix_minimal[0x401bf6]
> >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
> >> >> /usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
> >> >> ./posix_minimal[0x4017dc]
> >> >> ./posix_minimal[0x4016ed]
> >> >> ./posix_minimal[0x4011cd]
> >> >> /usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
> >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
> >> >> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
> >> >> Temps UCT limite expiré (core dumped)
> >> >> 
> >> >> It is the same output as when PTHREAD_WARNSW is active. Could you give me some
> >> >> hints why?
> >> > 
> >> > I already gave you some hints. I need to run the test code you sent.
> >> > But the test code you sent is wrong in the place where it enables
> >> > the PTHREAD_WARNSW bit.
> >> 
> >> The output of:
> >>  void mini( void *ptr )
> >>  {
> >>  
> >>  	uint8_t b;
> >>  	int ret1;
> >>  	int idx;
> >> 
> >>         printf("Starting posix test\n");
> >>  
> >>  	ec_port = malloc(sizeof(ecx_portt*));
> >>  
> >>  	if (setup_nic(ec_port,"rteth0") > 0) {
> >>  		   idx = getindex (ec_port);
> >>      		   /* setup datagram */
> >>          	   b = 0x0000;
> >>     	           setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
> >>     	           sizeof(b), &b );
> >>                    /* send data and wait for answer */
> >>                    pthread_set_mode_np(0, PTHREAD_WARNSW);
> >>                    wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
> >>         }
> >> }
> >> 
> >> and program without any PTHREAD_WARNSW are the same as the last post I gave you.
> >> So we can conclude that it was not setup_nic or malloc which trigger the
> >> SIGDEBUG handler.
> > 
> > It makes sense for malloc not to cause a SIGDEBUG, because malloc
> > does not always cause a switch to secondary mode. But for setup_nic
> > I really have doubts. Are you sure that the thread is not running
> > with the SCHED_OTHER policy and this is not the cause of both
> > behaviours (no mode switch on secondary mode operations, because the
> > thread is running in secondary mode, then switch when calling a
> > primary mode operation because of the automatic switch back to
> > secondary mode due to the SCHED_OTHER policy)?
> > 
> 
> Hi Gilles, 
> 
> With my old minimal test, there were no mode switch for setup_nic with SCHED_OTHER & SCHED_FIFO. The mode switch occurs only at the __wrap_send call (err RESCNT_IMBALANCE)
> 
> But I inserted this line yesterday in main() function to setup p_attr1: 
> pthread_attr_setinheritsched(&p_attr1, PTHREAD_EXPLICIT_SCHED);
> 
> With this, the behavior becomes normal, i.e:
> with SCHED_FIFO, there are 1 mode switch in setup_nic when calling __wrap_socket (which is valid), and after that there are no mode switch anymore.

It makes sense.

> with SCHED_OTHER, always the same mode switch at __wrap_send.

That does not really make sense. If the driver you use uses some
RTDM spinlock, it is possible that you have the same issue with RTDM
mutexes as was fixed recently in Xenomai 3:

https://git.xenomai.org/xenomai-3.git/commit/?id=ef0992d6278ccad0af594b388f19d6536ececb29

> 
> So basiclly, now its worked, but I don't understand why the setinheritsched call can hold the mode switch in __wrap_send while all others fail? 

Sorry, I do not understand your question. Without
PTHREAD_EXPLICIT_SCHED, the newly created thread uses the same
scheduling policy as the calling thread, which is SCHED_OTHER if you
do not do anything special (such as running the program with chrt).

-- 
					    Gilles.

Re: [Xenomai] Differents switch mode from differents Xenomai skin

[Huy Cong Vu]

----- Mail original -----
> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
> Cc: xenomai@xenomai.org
> Envoyé: Mardi 6 Janvier 2015 10:16:58
> Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin

> On Tue, Jan 06, 2015 at 10:09:30AM +0100, Huy Cong Vu wrote:
>> 
>> 
>> ----- Mail original -----
>> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> > Cc: xenomai@xenomai.org
>> > Envoyé: Lundi 5 Janvier 2015 17:58:13
>> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> 
>> > On Mon, Jan 05, 2015 at 11:30:39AM +0100, Huy Cong Vu wrote:
>> >> 
>> >> 
>> >> ----- Mail original -----
>> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> > Cc: xenomai@xenomai.org
>> >> > Envoyé: Mercredi 24 Décembre 2014 15:49:28
>> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> 
>> >> > On Wed, Dec 24, 2014 at 10:30:18AM +0100, Huy Cong Vu wrote:
>> >> >> 
>> >> >> 
>> >> >> ----- Mail original -----
>> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> >> > Cc: xenomai@xenomai.org
>> >> >> > Envoyé: Mercredi 24 Décembre 2014 01:29:12
>> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> >> 
>> >> >> > On Tue, Dec 23, 2014 at 05:58:42PM +0100, Huy Cong Vu wrote:
>> >> >> >> 
>> >> >> >> 
>> >> >> >> ----- Mail original -----
>> >> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> >> >> > Cc: xenomai@xenomai.org
>> >> >> >> > Envoyé: Mardi 23 Décembre 2014 17:46:59
>> >> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> >> >> 
>> >> >> >> > On Tue, Dec 23, 2014 at 05:43:41PM +0100, Huy Cong Vu wrote:
>> >> >> >> >> 
>> >> >> >> >> 
>> >> >> >> >> ----- Mail original -----
>> >> >> >> >> > De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> >> >> >> >> > À: "Huy Cong Vu" <huy-cong.vu@wandercraft.eu>
>> >> >> >> >> > Cc: xenomai@xenomai.org
>> >> >> >> >> > Envoyé: Mardi 23 Décembre 2014 17:35:35
>> >> >> >> >> > Objet: Re: [Xenomai] Differents switch mode from differents Xenomai skin
>> >> >> >> >> 
>> >> >> >> >> > On Tue, Dec 23, 2014 at 05:23:07PM +0100, Huy Cong Vu wrote:
>> >> >> >> >> >> void mini( void *ptr )
>> >> >> >> >> >> {
>> >> >> >> >> >> 
>> >> >> >> >> >> 
>> >> >> >> >> >> 	uint8_t b;
>> >> >> >> >> >> 	int ret1;
>> >> >> >> >> >> 	int idx;
>> >> >> >> >> >> 
>> >> >> >> >> >> 	pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> >> >> >> >>    printf("Starting posix test\n");
>> >> >> >> >> >> 
>> >> >> >> >> >> 	ec_port = malloc(sizeof(ecx_portt*));
>> >> >> >> >> >> 
>> >> >> >> >> >> 	if (setup_nic(ec_port,"rteth0") > 0) {
>> >> >> >> >> >> 		   idx = getindex (ec_port);
>> >> >> >> >> >>    		/* setup datagram */
>> >> >> >> >> >> 			b = 0x0000;
>> >> >> >> >> >>    		setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>> >> >> >> >> >>    		sizeof(b), &b );
>> >> >> >> >> >>    		/* send data and wait for answer */
>> >> >> >> >> >>    		wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> >> >> >> >> >> 	}
>> >> >> >> >> >> 	
>> >> >> >> >> >> }
>> >> >> >> >> > 
>> >> >> >> >> > Typically, as I already explained, what you do here is wrong: you
>> >> >> >> >> > should not arm the PTHREAD_WARNSW bit before call such as malloc or
>> >> >> >> >> > the calls in setup_nic, which switch to secondary mode.
>> >> >> >> >> 
>> >> >> >> >> Ok, should I call it laterly? It is just for detect mode switch
>> >> >> >> >> reason in fact
>> >> >> >> > 
>> >> >> >> > How to use PTHREAD_WARNSW is thoroughly documented, see:
>> >> >> >> > https://xenomai.org/2014/06/finding-spurious-relaxes/
>> >> >> >> > 
>> >> >> >> 
>> >> >> >> So perhaps I was misunderstanding this statement?
>> >> >> >> Then, you need to enable the warn_upon_switch capability on a per-thread basis.
>> >> >> >> For instance, a POSIX-based application would run this code from the thread to
>> >> >> >> monitor for spurious relaxes:
>> >> >> >> 
>> >> >> >>     /* Ask Xenomai to warn us upon switches to secondary mode. */
>> >> >> >>     pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >> >> >> 
>> >> >> >> Does that means that I must put the line into the thread with function calls
>> >> >> >> that cause mode switch?
>> >> >> >> I thought it means that I have to put the line in the threads of my program (in
>> >> >> >> my case mini() ).
>> >> >> > 
>> >> >> > Enabling this bit, causes every switch to secondary mode of the
>> >> >> > thread where you enabled it to send a signal to that thread. I do
>> >> >> > not understand what is so hard to understand about this.
>> >> >> 
>> >> >> Ok, so I guess I didn't understand this wrongly at least.
>> >> >> 
>> >> >> Suppose that I remove PTHREAD_WARNSW bit, here what I got in output:
>> >> >> SOEM (Simple Open EtherCAT Master)
>> >> >> Simple test
>> >> >> Starting posix test
>> >> >> Mode switch (reason bad functions call while holding mutex, or other unknown
>> >> >> issue), aborting. Backtrace:
>> >> >> ./posix_minimal[0x401bf6]
>> >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f94ef972cb0]
>> >> >> /usr/xenomai/lib/libpthread_rt.so.1(__wrap_send+0xd5)[0x7f94efd8f9f5]
>> >> >> ./posix_minimal[0x4017dc]
>> >> >> ./posix_minimal[0x4016ed]
>> >> >> ./posix_minimal[0x4011cd]
>> >> >> /usr/xenomai/lib/libpthread_rt.so.1(+0x5b45)[0x7f94efd8cb45]
>> >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f94ef96ae9a]
>> >> >> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f94ef28d3fd]
>> >> >> Temps UCT limite expiré (core dumped)
>> >> >> 
>> >> >> It is the same output as when PTHREAD_WARNSW is active. Could you give me some
>> >> >> hints why?
>> >> > 
>> >> > I already gave you some hints. I need to run the test code you sent.
>> >> > But the test code you sent is wrong in the place where it enables
>> >> > the PTHREAD_WARNSW bit.
>> >> 
>> >> The output of:
>> >>  void mini( void *ptr )
>> >>  {
>> >>  
>> >>  	uint8_t b;
>> >>  	int ret1;
>> >>  	int idx;
>> >> 
>> >>         printf("Starting posix test\n");
>> >>  
>> >>  	ec_port = malloc(sizeof(ecx_portt*));
>> >>  
>> >>  	if (setup_nic(ec_port,"rteth0") > 0) {
>> >>  		   idx = getindex (ec_port);
>> >>      		   /* setup datagram */
>> >>          	   b = 0x0000;
>> >>     	           setupdatagram (ec_port, &(ec_port->txbuf[idx]),0x0009, idx, 0x0000, 0x0103,
>> >>     	           sizeof(b), &b );
>> >>                    /* send data and wait for answer */
>> >>                    pthread_set_mode_np(0, PTHREAD_WARNSW);
>> >>                    wkc = srconfirm (ec_port, idx, EC_TIMEOUTRET3);
>> >>         }
>> >> }
>> >> 
>> >> and program without any PTHREAD_WARNSW are the same as the last post I gave you.
>> >> So we can conclude that it was not setup_nic or malloc which trigger the
>> >> SIGDEBUG handler.
>> > 
>> > It makes sense for malloc not to cause a SIGDEBUG, because malloc
>> > does not always cause a switch to secondary mode. But for setup_nic
>> > I really have doubts. Are you sure that the thread is not running
>> > with the SCHED_OTHER policy and this is not the cause of both
>> > behaviours (no mode switch on secondary mode operations, because the
>> > thread is running in secondary mode, then switch when calling a
>> > primary mode operation because of the automatic switch back to
>> > secondary mode due to the SCHED_OTHER policy)?
>> > 
>> 
>> Hi Gilles,
>> 
>> With my old minimal test, there were no mode switch for setup_nic with
>> SCHED_OTHER & SCHED_FIFO. The mode switch occurs only at the __wrap_send call
>> (err RESCNT_IMBALANCE)
>> 
>> But I inserted this line yesterday in main() function to setup p_attr1:
>> pthread_attr_setinheritsched(&p_attr1, PTHREAD_EXPLICIT_SCHED);
>> 
>> With this, the behavior becomes normal, i.e:
>> with SCHED_FIFO, there are 1 mode switch in setup_nic when calling __wrap_socket
>> (which is valid), and after that there are no mode switch anymore.
> 
> It makes sense.
> 
>> with SCHED_OTHER, always the same mode switch at __wrap_send.
> 
> That does not really make sense. If the driver you use uses some
> RTDM spinlock, it is possible that you have the same issue with RTDM
> mutexes as was fixed recently in Xenomai 3:
> 
> https://git.xenomai.org/xenomai-3.git/commit/?id=ef0992d6278ccad0af594b388f19d6536ececb29
> 

I'll try out Xenomai 3 to see if this issue still occurs.

>> 
>> So basiclly, now its worked, but I don't understand why the setinheritsched call
>> can hold the mode switch in __wrap_send while all others fail?
> 
> Sorry, I do not understand your question. Without
> PTHREAD_EXPLICIT_SCHED, the newly created thread uses the same
> scheduling policy as the calling thread, which is SCHED_OTHER if you
> do not do anything special (such as running the program with chrt).
>

Ok, I understand now, so my thread used a wrong scheduler in the first place that leads to wrong behaviors after. 
Thanks for the explanation!
  
> --
> 					    Gilles.

-- 
Huy Cong
Wandercraft SAS