[Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU

All of lore.kernel.org
 help / color / mirror / Atom feed

* [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
@ 2012-10-05  9:47 Thierry Bultel
  2012-10-05 10:10 ` Gilles Chanteperdrix
  2012-10-05 12:31 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 7+ messages in thread
From: Thierry Bultel @ 2012-10-05  9:47 UTC (permalink / raw)
  To: xenomai

Hi,

My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO

My test case is quite simple.
The main process is as such:

-----------------

int main ( ......


pthread_set_name_np(pthread_self(), "MAIN PROCESS");

if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
{
    LOG("pthread_set_mode_np FAILED\n");
    exit(0);
}

for (;;)
{
    struct timespec delay = { 10, 0 };
    nanosleep(&delay,NULL);
}

----------

The MSW counter keeps increasing, whereas no SIGXCPU is delivered:

[root@buildroot ~]# cat /proc/xenomai/stat 
CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          1131       0     00500080   99.6  ROOT
  0  717    95         189        0     00b40184    0.0  MAIN PROCESS
  0  0      0          381587     0     00000000    0.4  IRQ34: [timer]


The build command:

arm-linux-gcc -fmessage-length=0 -pipe -Wall -Werror -g -DNOT_USE_DYNAMIC_LOADING 
-I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai 
-D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
-I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai/posix 
-c /home/tbultel/workspace/agv/linux/simerimcan/sim_agv_can_main.c 
-o /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
-MMD -MF/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.d 
-I. -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/opt/can/include/canfestival-xenomai 
-I"="/usr/include/xenomai -I"="/usr/include/xenomai/posix


arm-linux-gcc -lrt -lpthread -rdynamic 
 -L/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib 
-lxenomai -lpthread_rt 
-Wl,@/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib/posix.wrappers 
-o /home/tbultel/workspace/agv/../bin/arm/sim_agv_can-xenomai 
/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_bus.o 
/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_erim_can_log.o


Thanks
Thierry


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
  2012-10-05  9:47 [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU Thierry Bultel
@ 2012-10-05 10:10 ` Gilles Chanteperdrix
  2012-10-05 10:22   ` Thierry Bultel
  2012-10-05 12:31 ` Gilles Chanteperdrix
  1 sibling, 1 reply; 7+ messages in thread
From: Gilles Chanteperdrix @ 2012-10-05 10:10 UTC (permalink / raw)
  To: Thierry Bultel; +Cc: xenomai

On 10/05/2012 11:47 AM, Thierry Bultel wrote:
> Hi,
> 
> My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
> on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO
> 
> My test case is quite simple.
> The main process is as such:
> 
> -----------------
> 
> int main ( ......
> 
> 
> pthread_set_name_np(pthread_self(), "MAIN PROCESS");
> 
> if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
> {
>     LOG("pthread_set_mode_np FAILED\n");
>     exit(0);
> }
> 
> for (;;)
> {
>     struct timespec delay = { 10, 0 };
>     nanosleep(&delay,NULL);
> }

mlockall missing.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
  2012-10-05 10:10 ` Gilles Chanteperdrix
@ 2012-10-05 10:22   ` Thierry Bultel
  0 siblings, 0 replies; 7+ messages in thread
From: Thierry Bultel @ 2012-10-05 10:22 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

Le 05/10/2012 12:10, Gilles Chanteperdrix a écrit :
> On 10/05/2012 11:47 AM, Thierry Bultel wrote:
>> Hi,
>>
>> My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
>> on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO
>>
>> My test case is quite simple.
>> The main process is as such:
>>
>> -----------------
>>
>> int main ( ......
>>
>>
>> pthread_set_name_np(pthread_self(), "MAIN PROCESS");
>>
>> if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
>> {
>>     LOG("pthread_set_mode_np FAILED\n");
>>     exit(0);
>> }
>>
>> for (;;)
>> {
>>     struct timespec delay = { 10, 0 };
>>     nanosleep(&delay,NULL);
>> }
> mlockall missing.
>


Sorry , Yes it is, I have not written down all the init part, (.....   )

but basically it is

#ifdef __XENO__

    /* Initialize realtime logging */

    rt_print_auto_init(1);

    /* Disable paging */

    if( mlockall(MCL_CURRENT | MCL_FUTURE) != 0 )

    {

        printf("ERROR: on mlockall errno=%d\n", errno);

        goto failure;

    }
#endif /* __XENO__ */




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
  2012-10-05  9:47 [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU Thierry Bultel
  2012-10-05 10:10 ` Gilles Chanteperdrix
@ 2012-10-05 12:31 ` Gilles Chanteperdrix
  2012-10-05 13:23   ` Thierry Bultel
  1 sibling, 1 reply; 7+ messages in thread
From: Gilles Chanteperdrix @ 2012-10-05 12:31 UTC (permalink / raw)
  To: Thierry Bultel; +Cc: xenomai

On 10/05/2012 11:47 AM, Thierry Bultel wrote:
> Hi,
> 
> My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
> on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO
> 
> My test case is quite simple.
> The main process is as such:
> 
> -----------------
> 
> int main ( ......
> 
> 
> pthread_set_name_np(pthread_self(), "MAIN PROCESS");
> 
> if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
> {
>     LOG("pthread_set_mode_np FAILED\n");
>     exit(0);
> }
> 
> for (;;)
> {
>     struct timespec delay = { 10, 0 };
>     nanosleep(&delay,NULL);
> }
> 
> ----------
> 
> The MSW counter keeps increasing, whereas no SIGXCPU is delivered:
> 
> [root@buildroot ~]# cat /proc/xenomai/stat 
> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>   0  0      0          1131       0     00500080   99.6  ROOT
>   0  717    95         189        0     00b40184    0.0  MAIN PROCESS
>   0  0      0          381587     0     00000000    0.4  IRQ34: [timer]
> 
> 
> The build command:
> 
> arm-linux-gcc -fmessage-length=0 -pipe -Wall -Werror -g -DNOT_USE_DYNAMIC_LOADING 
> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai 
> -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai/posix 
> -c /home/tbultel/workspace/agv/linux/simerimcan/sim_agv_can_main.c 
> -o /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
> -MMD -MF/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.d 
> -I. -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/opt/can/include/canfestival-xenomai 
> -I"="/usr/include/xenomai -I"="/usr/include/xenomai/posix
> 
> 
> arm-linux-gcc -lrt -lpthread -rdynamic 
>  -L/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib 
> -lxenomai -lpthread_rt 
> -Wl,@/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib/posix.wrappers 
> -o /home/tbultel/workspace/agv/../bin/arm/sim_agv_can-xenomai 
> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_bus.o 
> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_erim_can_log.o

In order to know if the link process worked correctly with this funky
argument order, I would use arm-linux-nm -s

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
  2012-10-05 12:31 ` Gilles Chanteperdrix
@ 2012-10-05 13:23   ` Thierry Bultel
  2012-10-05 13:30     ` Gilles Chanteperdrix
  0 siblings, 1 reply; 7+ messages in thread
From: Thierry Bultel @ 2012-10-05 13:23 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

Le 05/10/2012 14:31, Gilles Chanteperdrix a écrit :
> On 10/05/2012 11:47 AM, Thierry Bultel wrote:
>> Hi,
>>
>> My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
>> on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO
>>
>> My test case is quite simple.
>> The main process is as such:
>>
>> -----------------
>>
>> int main ( ......
>>
>>
>> pthread_set_name_np(pthread_self(), "MAIN PROCESS");
>>
>> if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
>> {
>>     LOG("pthread_set_mode_np FAILED\n");
>>     exit(0);
>> }
>>
>> for (;;)
>> {
>>     struct timespec delay = { 10, 0 };
>>     nanosleep(&delay,NULL);
>> }
>>
>> ----------
>>
>> The MSW counter keeps increasing, whereas no SIGXCPU is delivered:
>>
>> [root@buildroot ~]# cat /proc/xenomai/stat 
>> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>>   0  0      0          1131       0     00500080   99.6  ROOT
>>   0  717    95         189        0     00b40184    0.0  MAIN PROCESS
>>   0  0      0          381587     0     00000000    0.4  IRQ34: [timer]
>>
>>
>> The build command:
>>
>> arm-linux-gcc -fmessage-length=0 -pipe -Wall -Werror -g -DNOT_USE_DYNAMIC_LOADING 
>> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai 
>> -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
>> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai/posix 
>> -c /home/tbultel/workspace/agv/linux/simerimcan/sim_agv_can_main.c 
>> -o /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
>> -MMD -MF/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.d 
>> -I. -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/opt/can/include/canfestival-xenomai 
>> -I"="/usr/include/xenomai -I"="/usr/include/xenomai/posix
>>
>>
>> arm-linux-gcc -lrt -lpthread -rdynamic 
>>  -L/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib 
>> -lxenomai -lpthread_rt 
>> -Wl,@/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib/posix.wrappers 
>> -o /home/tbultel/workspace/agv/../bin/arm/sim_agv_can-xenomai 
>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_bus.o 
>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_erim_can_log.o
> In order to know if the link process worked correctly with this funky
> argument order, I would use arm-linux-nm -s
>

'arm-linux-nm -s' shows :

         U __wrap_clock_gettime
         U __wrap_close
         U __wrap_connect
         U __wrap_nanosleep
         U __wrap_printf
         U __wrap_puts
         U __wrap_socket

That gdb also confirms that

(gdb) r
Starting program: /root/sim_agv_can-xenomai
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x2ac82470 (LWP 1642)]
[SIMBUS] 03:58:32.955 MLOCKALL DONE
[SIMBUS] 03:58:32.975 Starting Bus simulator
[SIMBUS] 03:58:32.977 Alive
[SIMBUS] 03:58:33.979 Alive
^C
Program received signal SIGINT, Interrupt.
0x2ab03ee4 in __wrap_clock_nanosleep () from /usr/lib/libpthread_rt.so.1
(gdb)

...and my MSW still increases

What link argument order would you advise ?


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
  2012-10-05 13:23   ` Thierry Bultel
@ 2012-10-05 13:30     ` Gilles Chanteperdrix
  2012-10-08 14:42       ` Thierry Bultel
  0 siblings, 1 reply; 7+ messages in thread
From: Gilles Chanteperdrix @ 2012-10-05 13:30 UTC (permalink / raw)
  To: Thierry Bultel; +Cc: xenomai

On 10/05/2012 03:23 PM, Thierry Bultel wrote:
> Le 05/10/2012 14:31, Gilles Chanteperdrix a écrit :
>> On 10/05/2012 11:47 AM, Thierry Bultel wrote:
>>> Hi,
>>>
>>> My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
>>> on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO
>>>
>>> My test case is quite simple.
>>> The main process is as such:
>>>
>>> -----------------
>>>
>>> int main ( ......
>>>
>>>
>>> pthread_set_name_np(pthread_self(), "MAIN PROCESS");
>>>
>>> if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
>>> {
>>>     LOG("pthread_set_mode_np FAILED\n");
>>>     exit(0);
>>> }
>>>
>>> for (;;)
>>> {
>>>     struct timespec delay = { 10, 0 };
>>>     nanosleep(&delay,NULL);
>>> }
>>>
>>> ----------
>>>
>>> The MSW counter keeps increasing, whereas no SIGXCPU is delivered:
>>>
>>> [root@buildroot ~]# cat /proc/xenomai/stat 
>>> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>>>   0  0      0          1131       0     00500080   99.6  ROOT
>>>   0  717    95         189        0     00b40184    0.0  MAIN PROCESS
>>>   0  0      0          381587     0     00000000    0.4  IRQ34: [timer]
>>>
>>>
>>> The build command:
>>>
>>> arm-linux-gcc -fmessage-length=0 -pipe -Wall -Werror -g -DNOT_USE_DYNAMIC_LOADING 
>>> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai 
>>> -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
>>> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai/posix 
>>> -c /home/tbultel/workspace/agv/linux/simerimcan/sim_agv_can_main.c 
>>> -o /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
>>> -MMD -MF/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.d 
>>> -I. -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/opt/can/include/canfestival-xenomai 
>>> -I"="/usr/include/xenomai -I"="/usr/include/xenomai/posix
>>>
>>>
>>> arm-linux-gcc -lrt -lpthread -rdynamic 
>>>  -L/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib 
>>> -lxenomai -lpthread_rt 
>>> -Wl,@/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib/posix.wrappers 
>>> -o /home/tbultel/workspace/agv/../bin/arm/sim_agv_can-xenomai 
>>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
>>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_bus.o 
>>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_erim_can_log.o
>> In order to know if the link process worked correctly with this funky
>> argument order, I would use arm-linux-nm -s
>>
> 
> 'arm-linux-nm -s' shows :
> 
>          U __wrap_clock_gettime
>          U __wrap_close
>          U __wrap_connect
>          U __wrap_nanosleep
>          U __wrap_printf
>          U __wrap_puts
>          U __wrap_socket
> 
> That gdb also confirms that
> 
> (gdb) r
> Starting program: /root/sim_agv_can-xenomai
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> [New Thread 0x2ac82470 (LWP 1642)]
> [SIMBUS] 03:58:32.955 MLOCKALL DONE
> [SIMBUS] 03:58:32.975 Starting Bus simulator
> [SIMBUS] 03:58:32.977 Alive
> [SIMBUS] 03:58:33.979 Alive
> ^C
> Program received signal SIGINT, Interrupt.
> 0x2ab03ee4 in __wrap_clock_nanosleep () from /usr/lib/libpthread_rt.so.1
> (gdb)
> 
> ...and my MSW still increases
> 
> What link argument order would you advise ?

object firsts, libraries next. Libraries in the "logical" order, so, if
your .o use libpthread_rt, start with libpthread_rt, since libpthread_rt
use libxenomai, libxenomai comes next, since both of them use libtphread
and librt, libpthread and librt come next, etc...

IOW, the order provided by xeno-config.

Anyway, if you did not call pthread_setschedparam in a part of code
which you did not show (which is why we usually ask for a self-contained
test case, with full source, so that we do not have to guess what you
could have done or not), the main thread is running with SCHED_OTHER
policy, and automatically returns to secondary domain after having
switched to primary domain during nanosleep.

-- 
					    Gilles.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU
  2012-10-05 13:30     ` Gilles Chanteperdrix
@ 2012-10-08 14:42       ` Thierry Bultel
  0 siblings, 0 replies; 7+ messages in thread
From: Thierry Bultel @ 2012-10-08 14:42 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: xenomai

Le 05/10/2012 15:30, Gilles Chanteperdrix a écrit :
> On 10/05/2012 03:23 PM, Thierry Bultel wrote:
>> Le 05/10/2012 14:31, Gilles Chanteperdrix a écrit :
>>> On 10/05/2012 11:47 AM, Thierry Bultel wrote:
>>>> Hi,
>>>>
>>>> My config is linux-3.2.21+xenomai-2.6.1 ; ipipe-core-3.2.21-arm-1.patch,
>>>> on qemu-system-arm ; versatile express. I have CONFIG_SMP to NO
>>>>
>>>> My test case is quite simple.
>>>> The main process is as such:
>>>>
>>>> -----------------
>>>>
>>>> int main ( ......
>>>>
>>>>
>>>> pthread_set_name_np(pthread_self(), "MAIN PROCESS");
>>>>
>>>> if (pthread_set_mode_np(0, PTHREAD_WARNSW) != 0)
>>>> {
>>>>     LOG("pthread_set_mode_np FAILED\n");
>>>>     exit(0);
>>>> }
>>>>
>>>> for (;;)
>>>> {
>>>>     struct timespec delay = { 10, 0 };
>>>>     nanosleep(&delay,NULL);
>>>> }
>>>>
>>>> ----------
>>>>
>>>> The MSW counter keeps increasing, whereas no SIGXCPU is delivered:
>>>>
>>>> [root@buildroot ~]# cat /proc/xenomai/stat 
>>>> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>>>>   0  0      0          1131       0     00500080   99.6  ROOT
>>>>   0  717    95         189        0     00b40184    0.0  MAIN PROCESS
>>>>   0  0      0          381587     0     00000000    0.4  IRQ34: [timer]
>>>>
>>>>
>>>> The build command:
>>>>
>>>> arm-linux-gcc -fmessage-length=0 -pipe -Wall -Werror -g -DNOT_USE_DYNAMIC_LOADING 
>>>> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai 
>>>> -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
>>>> -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/xenomai/posix 
>>>> -c /home/tbultel/workspace/agv/linux/simerimcan/sim_agv_can_main.c 
>>>> -o /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
>>>> -MMD -MF/home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.d 
>>>> -I. -I/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/opt/can/include/canfestival-xenomai 
>>>> -I"="/usr/include/xenomai -I"="/usr/include/xenomai/posix
>>>>
>>>>
>>>> arm-linux-gcc -lrt -lpthread -rdynamic 
>>>>  -L/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib 
>>>> -lxenomai -lpthread_rt 
>>>> -Wl,@/home/tbultel/workspace/Buildroot/output/host/usr/arm-unknown-linux-gnueabi/sysroot/usr/lib/posix.wrappers 
>>>> -o /home/tbultel/workspace/agv/../bin/arm/sim_agv_can-xenomai 
>>>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_main.o 
>>>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_agv_can_bus.o 
>>>> /home/tbultel/workspace/agv/linux/simerimcan/build.xenomai/obj/sim_erim_can_log.o
>>> In order to know if the link process worked correctly with this funky
>>> argument order, I would use arm-linux-nm -s
>>>
>> 'arm-linux-nm -s' shows :
>>
>>          U __wrap_clock_gettime
>>          U __wrap_close
>>          U __wrap_connect
>>          U __wrap_nanosleep
>>          U __wrap_printf
>>          U __wrap_puts
>>          U __wrap_socket
>>
>> That gdb also confirms that
>>
>> (gdb) r
>> Starting program: /root/sim_agv_can-xenomai
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/libthread_db.so.1".
>> [New Thread 0x2ac82470 (LWP 1642)]
>> [SIMBUS] 03:58:32.955 MLOCKALL DONE
>> [SIMBUS] 03:58:32.975 Starting Bus simulator
>> [SIMBUS] 03:58:32.977 Alive
>> [SIMBUS] 03:58:33.979 Alive
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x2ab03ee4 in __wrap_clock_nanosleep () from /usr/lib/libpthread_rt.so.1
>> (gdb)
>>
>> ...and my MSW still increases
>>
>> What link argument order would you advise ?
> object firsts, libraries next. Libraries in the "logical" order, so, if
> your .o use libpthread_rt, start with libpthread_rt, since libpthread_rt
> use libxenomai, libxenomai comes next, since both of them use libtphread
> and librt, libpthread and librt come next, etc...
>
> IOW, the order provided by xeno-config.
>
> Anyway, if you did not call pthread_setschedparam in a part of code
> which you did not show (which is why we usually ask for a self-contained
> test case, with full source, so that we do not have to guess what you
> could have done or not), the main thread is running with SCHED_OTHER
> policy, and automatically returns to secondary domain after having
> switched to primary domain during nanosleep.
Many thanks, SCHED_OTHER was the point

Cheers
Thierry



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2012-10-08 14:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-05  9:47 [Xenomai] nanosleep and clock_nanosleep increase MSW counter without SIGXCPU Thierry Bultel
2012-10-05 10:10 ` Gilles Chanteperdrix
2012-10-05 10:22   ` Thierry Bultel
2012-10-05 12:31 ` Gilles Chanteperdrix
2012-10-05 13:23   ` Thierry Bultel
2012-10-05 13:30     ` Gilles Chanteperdrix
2012-10-08 14:42       ` Thierry Bultel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.