[Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Paolo Minazzi]

Hi to all.
I'm Paolo Minazzi and we use a port of xenomai on our arm Marvel mv78100 
board.
We use kernel 2.6.31.8 and xenomai 2.5.6.
All works well.
We have developed an application that use the xenomai features.
We can debug it with gdb, native or gdb client/server ver 6.8a.

I have tried also other gdb version, also the new 7.5.1.

Sometimes *** during debugging ***  we can generate a very strange problem.
When the realtime tasks execute the rt_task_sleep(), the rt_task_sleep() 
does not return anymore !
When we enter in this strange condition, the system is usable, linux 
works normally, but the realtime features do not works.

The problem is not easily reproducible.
I have tried in a lot of way to write a simple program for generating 
the problem, but I am not able to do it.

When I can reach the bug conditionm, If I run a simple xenomai test 
program with
- 20 realtime tasks
- 1 irq external line (generated every 2ms from a Fujitsu microcontroller)

     #include <...>

     #define N 20

     void tsk(void *arg)
     {
         struct data_task_struct *p = arg;
         while (1)
         {
             rt_task_sleep(p->delay);
             cnt++;
         }
     }

     int main(int argc, char* argv[])
     {
         mlockall(MCL_CURRENT|MCL_FUTURE);

         rt_timer_set_mode ( 0 );
         rt_task_set_mode(0, 0, NULL);

         MapRegistersARM();

         InitIrq();
         enable_irq_fujitsu();

         for (i=0; i<N; i++)
         {
             char s[1024];
             sprintf(s,"demo%d",i);
             data_task[i].cnt = 0;
             data_task[i].delay = 1000000 * (1+i);
             rt_task_create(&data_task[i].tsk, s, 0, i, T_JOINABLE);
             rt_task_start(&data_task[i].tsk, &tsk, &data_task[i]);
         }

         while(1)
         {
             int i;
             printf("[ %4d ]    ",cnt2ms);
             for (i=0; i<N; i++)
                 printf("%3d ",data_task[i].cnt);
             usleep(10000);
             printf("\n");
         }
     }

I can get the following information :

[========================= cat /proc/xenomai/sched 
==============================]
     CPU  PID    CLASS  PRI      TIMEOUT     TIMEBASE   STAT       NAME
       0  0      idle    -1      -           master     R          ROOT
       0  2746   rt     257      -           master     W          Irq2ms
       0  2747   rt       0      159ms591us  master     D          demo0
       0  2748   rt       1      160ms689us  master     D          demo1
       0  2749   rt       2      162ms19us   master     D          demo2
       0  2750   rt       3      163ms350us  master     D          demo3
       0  2751   rt       4      164ms685us  master     D          demo4
       0  2752   rt       5      166ms33us   master     D          demo5
       0  2753   rt       6      167ms359us  master     D          demo6
       0  2754   rt       7      168ms691us  master     D          demo7
       0  2755   rt       8      170ms17us   master     D          demo8
       0  2756   rt       9      171ms341us  master     D          demo9
       0  2757   rt      10      172ms670us  master     D          demo10
       0  2758   rt      11      174ms14us   master     D          demo11
       0  2759   rt      12      175ms347us  master     D          demo12
       0  2760   rt      13      176ms673us  master     D          demo13
       0  2761   rt      14      178ms5us    master     D          demo14
       0  2762   rt      15      179ms332us  master     D          demo15
       0  2763   rt      16      180ms664us  master     D          demo16
       0  2764   rt      17      182ms12us   master     D          demo17
       0  2765   rt      18      183ms338us  master     D          demo18
       0  2766   rt      19      184ms664us  master     D          demo19

     The TIMEOUT values runs correctly.



[========================= cat /proc/xenomai/stat 
==============================]
     CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
       0  0      0          976221     0     00500080   99.9  ROOT
       0  2746   0          68477      0     00300182    0.0  Irq2ms
       0  2747   0          1          0     00300184    0.0  demo0
       0  2748   0          1          0     00300184    0.0  demo1
       0  2749   0          1          0     00300184    0.0  demo2
       0  2750   0          1          0     00300184    0.0  demo3
       0  2751   0          1          0     00300184    0.0  demo4
       0  2752   0          1          0     00300184    0.0  demo5
       0  2753   0          1          0     00300184    0.0  demo6
       0  2754   0          1          0     00300184    0.0  demo7
       0  2755   0          1          0     00300184    0.0  demo8
       0  2756   0          1          0     00300184    0.0  demo9
       0  2757   0          1          0     00300184    0.0  demo10
       0  2758   0          1          0     00300184    0.0  demo11
       0  2759   0          1          0     00300184    0.0  demo12
       0  2760   0          1          0     00300184    0.0  demo13
       0  2761   0          1          0     00300184    0.0  demo14
       0  2762   0          1          0     00300184    0.0  demo15
       0  2763   0          1          0     00300184    0.0  demo16
       0  2764   0          1          0     00300184    0.0  demo17
       0  2765   0          1          0     00300184    0.0  demo18
       0  2766   0          1          0     00300184    0.0  demo19
       0  0      0          2551886    0     00000000    0.0  IRQ8: [timer]
       0  0      0          0          0     00000000    0.0  IRQ44: 
rtdm_eth
       0  0      0          68477      0     00000000    0.0  IRQ58: 
IntFujitsu

     The values in in the CSW column (ROOT, Irq2ms, IRQ8, IRQ58) runs 
correctly.



[========================= cat /proc/xenomai/irq 
==============================]
     IRQ         CPU0
       8:     2584003         [timer]
      44:           0         rtdm_eth
      58:      993694         IntFujitsu
      98:      404350         [virtual]

     The values [timer] and IntFujitsu in the CPU0 columns runs correctly.



[========================= cat /proc/xenomai/timer 
==============================]
     
status=on:setup=455:clock=1863202575863:timerdev=orion_tick:clockdev=orion_clocksource

     The value clock run correctly.



[========================= cat /proc/xenomai/hal 
==============================]
     1.16-02



[========================= date ==============================]
     The date program works correclty.



[========================= cat /proc/xenomai/latency 
==============================]
     4300




[========================= cat /proc/xenomai/timebases 
==============================]
     NAME       RESOLUTION     JIFFIES   STATUS
     master              1         n/a   enabled,set



[========================= cat /proc/xenomai/heap 
==============================]
     size=126976:used=16:pagesz=4096  (global sem heap)
     size=4161536:used=43552:pagesz=512  (main heap)
     size=129536:used=0:pagesz=512  (stack pool)
     size=8192:used=0:pagesz=4096  (private sem heap [2745])




I can generate the problem only debugging with gdb, otherwise there is 
no problem.

Can you help me to undertand what happen ?
Have you got an idea ? do you need other information ?

Thanks for your time.

Paolo Minazzi

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/06/2013 12:40 PM, Paolo Minazzi wrote:

> I can generate the problem only debugging with gdb, otherwise there is 
> no problem.
> 
> Can you help me to undertand what happen ?
> Have you got an idea ? do you need other information ?


In case it is something which was fixed since Xenomai 2.5.6, could you
try Xenomai 2.6.2.1?

-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Paolo Minazzi]

Il 07/03/2013 13.38, Gilles Chanteperdrix ha scritto:
> On 03/07/2013 10:08 AM, Paolo Minazzi wrote:
>
>> Il 06/03/2013 13.36, Gilles Chanteperdrix ha scritto:
>>> On 03/06/2013 01:31 PM, Paolo Minazzi wrote:
>>>
>>>> Il 06/03/2013 13.06, Gilles Chanteperdrix ha scritto:
>>>>> On 03/06/2013 12:40 PM, Paolo Minazzi wrote:
>>>>>
>>>>>> I can generate the problem only debugging with gdb, otherwise there is
>>>>>> no problem.
>>>>>>
>>>>>> Can you help me to undertand what happen ?
>>>>>> Have you got an idea ? do you need other information ?
>>>>> In case it is something which was fixed since Xenomai 2.5.6, could you
>>>>> try Xenomai 2.6.2.1?
>>>>>
>>>> I have not done the port.
>>>> This work is done by an external firm.
>>>> I know well enough the linux kernel, but very very little the xenomai
>>>> internals.
>>> You can use Xenomai 2.6.2.1 with the same version of the I-pipe kernel,
>>> and the I-pipe kernel is the only thing which needs to be ported.
>>>
>>>> I could try ... but it is not easy ....
>>> It should be as easy as:
>>> - keep your kernel patched with the I-pipe patch
>>> - download the newest version of Xenomai, that is 2.6.2.1
>>> - follow the installation instructions, here:
>>> http://www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/
>>>
>>>> The problem appear only using gdb .... any ideas ?
>>> Could be the timer programmed for a too short delay, could be something
>>> we already fixed, could be a new bug... Really, testing rapidly the last
>>> version will make us win a lot of time if this is an issue already fixed.
>>>
>>>
>> I Gilles,
>> I have ported to 2.6.1 without problems.
>> To 2.6.2 and 2.6.2.1 I need to add a gcc built-in. My compiler is
>
> pass --with-atomic-ops=ad-hoc to configure script, this will avoid the
> builtins.
>
>> gcc-4.3.2 and does not have some built-in atomic function.
>> After this I need to change the switch.S because my assembler cannot
>
> switch.S has been compiling for ages, way before gcc 4.4. Could you show
> me the warning you get?
>
>> compile it. Maybe a newer compiler (gcc>= 4.4) could solve all these
>> problems, but for me this is not a valid solution because other
>> developers of us use a cygwin compiler. We should built a new cygwin
>> compiler ... the libs will be different and so I will have problem with
>> shared libraries .... too complex to solve a sporadic bug using gdb ....
>> I can try to see the 2.6.1.
>
> The idea of asking you to try 2.6.2.1 is not to ask you to switch to it,
> but simply to do a quick test to see if you can reproduce the issue.
>
>

   CC      drivers/xenomai/testing/switchtest.o
   CC      drivers/xenomai/testing/timerbench.o
   LD      drivers/xenomai/testing/xeno_timerbench.o
   LD      drivers/xenomai/testing/xeno_switchtest.o
   LD      drivers/xenomai/testing/built-in.o
   LD      drivers/xenomai/built-in.o
   LD      drivers/built-in.o
   CC      arch/arm/xenomai/hal.o
   AS      arch/arm/xenomai/switch.o
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S: 
Assembler messages:
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:156: 
Error: bad instruction `arm( stmia ip!,{r4-sl,fp,sp,lr})'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:157: 
Error: bad instruction `thumb( stmia ip!,{r4-sl,fp})'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:158: 
Error: bad instruction `thumb( str sp,[ip],#4)'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:159: 
Error: bad instruction `thumb( str lr,[ip],#4)'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:170: 
Error: bad instruction `arm( add r4,r2,#28)'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:171: 
Error: bad instruction `arm( ldmia r4,{r4-sl,fp,sp,pc})'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:172: 
Error: bad instruction `thumb( add ip,r2,#28)'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:173: 
Error: bad instruction `thumb( ldmia ip!,{r4-sl,fp})'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:174: 
Error: bad instruction `thumb( ldr sp,[ip],#4)'
/home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:175: 
Error: bad instruction `thumb( ldr pc,[ip])'
make[2]: *** [arch/arm/xenomai/switch.o] Error 1
make[1]: *** [arch/arm/xenomai] Error 2
make: *** [sub-make] Error 2



**************************************
arm-mv5sft-linux-gnueabi-gcc -v
**************************************
Using built-in specs.
Target: arm-mv5sft-linux-gnueabi
Configured with: /home/seugene/sdk/targets/src/gcc-4.3.2/configure 
--build=i486-build_pc-linux-gnu --host=i486-build_pc-linux-gnu 
--target=arm-mv5sft-linux-gnueabi 
--prefix=/home/seugene/sdk/targets/arm-mv5sft-linux-gnueabi/cross 
--with-sysroot=/home/seugene/sdk/targets/arm-mv5sft-linux-gnueabi/cross/arm-mv5sft-linux-gnueabi//sys-root 
--enable-languages=c,c++,fortran,java --disable-multilib 
--with-arch=armv5te --with-float=soft 
--with-gmp=/home/seugene/sdk/targets/arm-mv5sft-linux-gnueabi/cross 
--with-mpfr=/home/seugene/sdk/targets/arm-mv5sft-linux-gnueabi/cross 
--with-pkgversion=sdk3.2rc1-ct-ng-1.4.1 --disable-sjlj-exceptions 
--enable-__cxa_atexit 
--with-local-prefix=/home/seugene/sdk/targets/arm-mv5sft-linux-gnueabi/cross/arm-mv5sft-linux-gnueabi//sys-root 
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.3.2 (sdk3.2rc1-ct-ng-1.4.1)


**************************************
arm-mv5sft-linux-gnueabi-as -v
**************************************
GNU assembler version 2.18.50 (arm-mv5sft-linux-gnueabi) using BFD 
version (GNU Binutils) 2.18.50.20080215

Thanks
Paolo

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/07/2013 01:53 PM, Paolo Minazzi wrote:

> Il 07/03/2013 13.38, Gilles Chanteperdrix ha scritto:
>> On 03/07/2013 10:08 AM, Paolo Minazzi wrote:
>>
>>> Il 06/03/2013 13.36, Gilles Chanteperdrix ha scritto:
>>>> On 03/06/2013 01:31 PM, Paolo Minazzi wrote:
>>>>
>>>>> Il 06/03/2013 13.06, Gilles Chanteperdrix ha scritto:
>>>>>> On 03/06/2013 12:40 PM, Paolo Minazzi wrote:
>>>>>>
>>>>>>> I can generate the problem only debugging with gdb, otherwise there is
>>>>>>> no problem.
>>>>>>>
>>>>>>> Can you help me to undertand what happen ?
>>>>>>> Have you got an idea ? do you need other information ?
>>>>>> In case it is something which was fixed since Xenomai 2.5.6, could you
>>>>>> try Xenomai 2.6.2.1?
>>>>>>
>>>>> I have not done the port.
>>>>> This work is done by an external firm.
>>>>> I know well enough the linux kernel, but very very little the xenomai
>>>>> internals.
>>>> You can use Xenomai 2.6.2.1 with the same version of the I-pipe kernel,
>>>> and the I-pipe kernel is the only thing which needs to be ported.
>>>>
>>>>> I could try ... but it is not easy ....
>>>> It should be as easy as:
>>>> - keep your kernel patched with the I-pipe patch
>>>> - download the newest version of Xenomai, that is 2.6.2.1
>>>> - follow the installation instructions, here:
>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/
>>>>
>>>>> The problem appear only using gdb .... any ideas ?
>>>> Could be the timer programmed for a too short delay, could be something
>>>> we already fixed, could be a new bug... Really, testing rapidly the last
>>>> version will make us win a lot of time if this is an issue already fixed.
>>>>
>>>>
>>> I Gilles,
>>> I have ported to 2.6.1 without problems.
>>> To 2.6.2 and 2.6.2.1 I need to add a gcc built-in. My compiler is
>>
>> pass --with-atomic-ops=ad-hoc to configure script, this will avoid the
>> builtins.
>>
>>> gcc-4.3.2 and does not have some built-in atomic function.
>>> After this I need to change the switch.S because my assembler cannot
>>
>> switch.S has been compiling for ages, way before gcc 4.4. Could you show
>> me the warning you get?
>>
>>> compile it. Maybe a newer compiler (gcc>= 4.4) could solve all these
>>> problems, but for me this is not a valid solution because other
>>> developers of us use a cygwin compiler. We should built a new cygwin
>>> compiler ... the libs will be different and so I will have problem with
>>> shared libraries .... too complex to solve a sporadic bug using gdb ....
>>> I can try to see the 2.6.1.
>>
>> The idea of asking you to try 2.6.2.1 is not to ask you to switch to it,
>> but simply to do a quick test to see if you can reproduce the issue.
>>
>>
> 
>    CC      drivers/xenomai/testing/switchtest.o
>    CC      drivers/xenomai/testing/timerbench.o
>    LD      drivers/xenomai/testing/xeno_timerbench.o
>    LD      drivers/xenomai/testing/xeno_switchtest.o
>    LD      drivers/xenomai/testing/built-in.o
>    LD      drivers/xenomai/built-in.o
>    LD      drivers/built-in.o
>    CC      arch/arm/xenomai/hal.o
>    AS      arch/arm/xenomai/switch.o
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S: 
> Assembler messages:
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:156: 
> Error: bad instruction `arm( stmia ip!,{r4-sl,fp,sp,lr})'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:157: 
> Error: bad instruction `thumb( stmia ip!,{r4-sl,fp})'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:158: 
> Error: bad instruction `thumb( str sp,[ip],#4)'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:159: 
> Error: bad instruction `thumb( str lr,[ip],#4)'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:170: 
> Error: bad instruction `arm( add r4,r2,#28)'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:171: 
> Error: bad instruction `arm( ldmia r4,{r4-sl,fp,sp,pc})'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:172: 
> Error: bad instruction `thumb( add ip,r2,#28)'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:173: 
> Error: bad instruction `thumb( ldmia ip!,{r4-sl,fp})'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:174: 
> Error: bad instruction `thumb( ldr sp,[ip],#4)'
> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:175: 
> Error: bad instruction `thumb( ldr pc,[ip])'
> make[2]: *** [arch/arm/xenomai/switch.o] Error 1
> make[1]: *** [arch/arm/xenomai] Error 2
> make: *** [sub-make] Error 2


The issue is not the compiler, the issue is with the linux kernel you
use. Could you put me a source tarball on some ftp site?

Please try adding:
#define ARM(x...)	x
#define	THUMB(x...)

At the top of switch.S


-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/07/2013 02:42 PM, Paolo Minazzi wrote:

> Il 07/03/2013 13.57, Gilles Chanteperdrix ha scritto:
>> #define ARM(x...)	x
>> #define	THUMB(x...)
> I have a problem of double definition of  __xn_tscinfo
> 
> #make
> 2ms.c: In function 'InitIrq':
> 2ms.c:182: warning: incompatible implicit declaration of built-in 
> function 'exit'
> /DVD/xenomai-2.6.2.1/src/skins/common/.libs/libxenomai.a(libxenomai_la-bind.o):(.data+0x0): 
> multiple definition of `__xn_tscinfo'
> /DVD/xenomai-2.6.2.1/src/skins/native/.libs/libnative.a(libnative_la-init.o):(.data+0x4): 
> first defined here
> collect2: ld returned 1 exit status
> make: *** [All] Error 1
> 
> 
> __xn_tscinfo is defined in src/include/asm/xenomai/bits/bind.h
> 
> ...
> ...
> #include <asm-generic/xenomai/bits/bind.h>
> #include <asm/xenomai/syscall.h>
> 
> struct __xn_full_tscinfo __xn_tscinfo = {
>          .kinfo = {
>                  .type = -1,
>          },
> };
> ...
> ...
> 
> It is strange define a struct in a .h file.


Right, normally this file should only be included in
src/skins/common/bind.c, but it happens to be included in all skins.
Will fix.

-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/08/2013 07:17 AM, Gilles Chanteperdrix wrote:

> On 03/07/2013 02:42 PM, Paolo Minazzi wrote:
> 
>> Il 07/03/2013 13.57, Gilles Chanteperdrix ha scritto:
>>> #define ARM(x...)	x
>>> #define	THUMB(x...)
>> I have a problem of double definition of  __xn_tscinfo
>>
>> #make
>> 2ms.c: In function 'InitIrq':
>> 2ms.c:182: warning: incompatible implicit declaration of built-in 
>> function 'exit'
>> /DVD/xenomai-2.6.2.1/src/skins/common/.libs/libxenomai.a(libxenomai_la-bind.o):(.data+0x0): 
>> multiple definition of `__xn_tscinfo'
>> /DVD/xenomai-2.6.2.1/src/skins/native/.libs/libnative.a(libnative_la-init.o):(.data+0x4): 
>> first defined here
>> collect2: ld returned 1 exit status
>> make: *** [All] Error 1
>>
>>
>> __xn_tscinfo is defined in src/include/asm/xenomai/bits/bind.h
>>
>> ...
>> ...
>> #include <asm-generic/xenomai/bits/bind.h>
>> #include <asm/xenomai/syscall.h>
>>
>> struct __xn_full_tscinfo __xn_tscinfo = {
>>          .kinfo = {
>>                  .type = -1,
>>          },
>> };
>> ...
>> ...
>>
>> It is strange define a struct in a .h file.
> 
> 
> Right, normally this file should only be included in
> src/skins/common/bind.c, but it happens to be included in all skins.
> Will fix.
> 

Could you try to compile again static libraries with the following patch
applied?

diff --git a/include/asm-nios2/bits/bind.h b/include/asm-nios2/bits/bind.h
index 067e7e2..668d8b8 100644
--- a/include/asm-nios2/bits/bind.h
+++ b/include/asm-nios2/bits/bind.h
@@ -12,7 +12,7 @@

 #include <asm-generic/xenomai/bits/bind.h>

-__attribute__((weak)) volatile void *xeno_nios2_hrclock = NULL;
+volatile void *xeno_nios2_hrclock = NULL;

 static inline void xeno_nios2_features_check(struct xnfeatinfo *finfo)
 {
diff --git a/include/asm-sh/bits/bind.h b/include/asm-sh/bits/bind.h
index 3b2b54d..bd25f80 100644
--- a/include/asm-sh/bits/bind.h
+++ b/include/asm-sh/bits/bind.h
@@ -14,10 +14,8 @@

 struct xnarch_tsc_area;

-__attribute__((weak))
 volatile struct xnarch_tsc_area *xeno_sh_tsc = NULL;

-__attribute__((weak))
 volatile unsigned long *xeno_sh_tcnt = NULL;

 static volatile void *__xeno_kmem_map(unsigned long pa, unsigned int
pagesz)
diff --git a/src/skins/native/init.c b/src/skins/native/init.c
index 2c36444..5d433b3 100644
--- a/src/skins/native/init.c
+++ b/src/skins/native/init.c
@@ -24,7 +24,7 @@
 #include <pthread.h>
 #include <native/syscall.h>
 #include <native/task.h>
-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __native_muxid = -1;
 static int fork_handler_registered;
diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
index 332081a..83d27a6 100644
--- a/src/skins/posix/init.c
+++ b/src/skins/posix/init.c
@@ -30,7 +30,7 @@
 #include <posix/mutex.h>
 #include <rtdk.h>

-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __pse51_muxid = -1;
 int __pse51_rtdm_muxid = -1;
diff --git a/src/skins/psos+/init.c b/src/skins/psos+/init.c
index b72825f..5098f91 100644
--- a/src/skins/psos+/init.c
+++ b/src/skins/psos+/init.c
@@ -20,7 +20,7 @@
 #include <errno.h>
 #include <sys/mman.h>
 #include <psos+/psos.h>
-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __psos_muxid = -1;

diff --git a/src/skins/rtdm/init.c b/src/skins/rtdm/init.c
index dbbcbb1..9672486 100644
--- a/src/skins/rtdm/init.c
+++ b/src/skins/rtdm/init.c
@@ -21,7 +21,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <rtdm/syscall.h>
-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __rtdm_muxid = -1;

diff --git a/src/skins/uitron/init.c b/src/skins/uitron/init.c
index a6cc77f..0ffc8bd 100644
--- a/src/skins/uitron/init.c
+++ b/src/skins/uitron/init.c
@@ -20,7 +20,7 @@
 #include <errno.h>
 #include <sys/mman.h>
 #include <uitron/uitron.h>
-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __uitron_muxid = -1;

diff --git a/src/skins/vrtx/init.c b/src/skins/vrtx/init.c
index 8a81660..d3d6cdb 100644
--- a/src/skins/vrtx/init.c
+++ b/src/skins/vrtx/init.c
@@ -23,7 +23,7 @@
 #include <stdlib.h>
 #include <pthread.h>
 #include <vrtx/vrtx.h>
-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __vrtx_muxid = -1;

diff --git a/src/skins/vxworks/init.c b/src/skins/vxworks/init.c
index 181b575..b2cdad4 100644
--- a/src/skins/vxworks/init.c
+++ b/src/skins/vxworks/init.c
@@ -23,7 +23,7 @@
 #include <stdlib.h>
 #include <pthread.h>
 #include <vxworks/vxworks.h>
-#include <asm/xenomai/bits/bind.h>
+#include <asm-generic/xenomai/bits/bind.h>

 int __vxworks_muxid = -1;



-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Paolo Minazzi]

Il 07/03/2013 13.57, Gilles Chanteperdrix ha scritto:
> On 03/07/2013 01:53 PM, Paolo Minazzi wrote:
>
>> Il 07/03/2013 13.38, Gilles Chanteperdrix ha scritto:
>>> On 03/07/2013 10:08 AM, Paolo Minazzi wrote:
>>>
>>>> Il 06/03/2013 13.36, Gilles Chanteperdrix ha scritto:
>>>>> On 03/06/2013 01:31 PM, Paolo Minazzi wrote:
>>>>>
>>>>>> Il 06/03/2013 13.06, Gilles Chanteperdrix ha scritto:
>>>>>>> On 03/06/2013 12:40 PM, Paolo Minazzi wrote:
>>>>>>>
>>>>>>>> I can generate the problem only debugging with gdb, otherwise there is
>>>>>>>> no problem.
>>>>>>>>
>>>>>>>> Can you help me to undertand what happen ?
>>>>>>>> Have you got an idea ? do you need other information ?
>>>>>>> In case it is something which was fixed since Xenomai 2.5.6, could you
>>>>>>> try Xenomai 2.6.2.1?
>>>>>>>
>>>>>> I have not done the port.
>>>>>> This work is done by an external firm.
>>>>>> I know well enough the linux kernel, but very very little the xenomai
>>>>>> internals.
>>>>> You can use Xenomai 2.6.2.1 with the same version of the I-pipe kernel,
>>>>> and the I-pipe kernel is the only thing which needs to be ported.
>>>>>
>>>>>> I could try ... but it is not easy ....
>>>>> It should be as easy as:
>>>>> - keep your kernel patched with the I-pipe patch
>>>>> - download the newest version of Xenomai, that is 2.6.2.1
>>>>> - follow the installation instructions, here:
>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/
>>>>>
>>>>>> The problem appear only using gdb .... any ideas ?
>>>>> Could be the timer programmed for a too short delay, could be something
>>>>> we already fixed, could be a new bug... Really, testing rapidly the last
>>>>> version will make us win a lot of time if this is an issue already fixed.
>>>>>
>>>>>
>>>> I Gilles,
>>>> I have ported to 2.6.1 without problems.
>>>> To 2.6.2 and 2.6.2.1 I need to add a gcc built-in. My compiler is
>>> pass --with-atomic-ops=ad-hoc to configure script, this will avoid the
>>> builtins.
>>>
>>>> gcc-4.3.2 and does not have some built-in atomic function.
>>>> After this I need to change the switch.S because my assembler cannot
>>> switch.S has been compiling for ages, way before gcc 4.4. Could you show
>>> me the warning you get?
>>>
>>>> compile it. Maybe a newer compiler (gcc>= 4.4) could solve all these
>>>> problems, but for me this is not a valid solution because other
>>>> developers of us use a cygwin compiler. We should built a new cygwin
>>>> compiler ... the libs will be different and so I will have problem with
>>>> shared libraries .... too complex to solve a sporadic bug using gdb ....
>>>> I can try to see the 2.6.1.
>>> The idea of asking you to try 2.6.2.1 is not to ask you to switch to it,
>>> but simply to do a quick test to see if you can reproduce the issue.
>>>
>>>
>>     CC      drivers/xenomai/testing/switchtest.o
>>     CC      drivers/xenomai/testing/timerbench.o
>>     LD      drivers/xenomai/testing/xeno_timerbench.o
>>     LD      drivers/xenomai/testing/xeno_switchtest.o
>>     LD      drivers/xenomai/testing/built-in.o
>>     LD      drivers/xenomai/built-in.o
>>     LD      drivers/built-in.o
>>     CC      arch/arm/xenomai/hal.o
>>     AS      arch/arm/xenomai/switch.o
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:
>> Assembler messages:
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:156:
>> Error: bad instruction `arm( stmia ip!,{r4-sl,fp,sp,lr})'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:157:
>> Error: bad instruction `thumb( stmia ip!,{r4-sl,fp})'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:158:
>> Error: bad instruction `thumb( str sp,[ip],#4)'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:159:
>> Error: bad instruction `thumb( str lr,[ip],#4)'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:170:
>> Error: bad instruction `arm( add r4,r2,#28)'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:171:
>> Error: bad instruction `arm( ldmia r4,{r4-sl,fp,sp,pc})'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:172:
>> Error: bad instruction `thumb( add ip,r2,#28)'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:173:
>> Error: bad instruction `thumb( ldmia ip!,{r4-sl,fp})'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:174:
>> Error: bad instruction `thumb( ldr sp,[ip],#4)'
>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:175:
>> Error: bad instruction `thumb( ldr pc,[ip])'
>> make[2]: *** [arch/arm/xenomai/switch.o] Error 1
>> make[1]: *** [arch/arm/xenomai] Error 2
>> make: *** [sub-make] Error 2
>
> The issue is not the compiler, the issue is with the linux kernel you
> use. Could you put me a source tarball on some ftp site?
>
> Please try adding:
> #define ARM(x...)	x
> #define	THUMB(x...)
>
> At the top of switch.S
>
>
Hi Gill,
2.6.2.1 seems work ok with a normal xenomai application.
But testing our complex application (to seach the gdb bug 
/rt_task_sleep) I found an other small problem.
Today I have studied this new problem that can be shown and produced 
with a simple example.

#include <sys/mman.h>
#include <native/task.h>
#include <native/timer.h>
#include <native/mutex.h>
#include <native/sem.h>
#include <pthread.h>

// PRIO=0 make a fault ! Other values are good
#define PRIO 0

RT_TASK tsk;

void fn(void *arg)
{
         while (1)
         {
                 rt_task_sleep(1000000);
         }
}

int main(int argc, char *argv[])
{
         mlockall(MCL_CURRENT | MCL_FUTURE);

         rt_timer_set_mode(0);
         rt_task_set_mode(0, 0, /* T_WARNSW , */ NULL);

         while (1)
         {
                 rt_task_create(&tsk, "demo", 0, PRIO, T_JOINABLE);
                 // rt_task_start(&tsk, &fn, 0);
                 rt_task_suspend(&tsk);
                 rt_task_delete(&tsk);
                 rt_task_join(&tsk);
         }

This is the log :

/ # /D/main
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 874d4000
[00000000] *pgd=01557031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT
Modules linked in: dp
CPU: 0    Not tainted  (2.6.31.8 #15)
PC is at losyscall_event+0x218/0x238
LR is at schedule+0x46c/0x50c
pc : [<8008d930>]    lr : [<8025b1ac>]    psr: a0000013
sp : 80d0def8  ip : fffffe00  fp : 80d0df1c
r10: 00000000  r9 : 803102a0  r8 : 00000018
r7 : 00000000  r6 : 80d0dfb0  r5 : 88031210  r4 : 00000001
r3 : 00000000  r2 : 00b00231  r1 : 87839360  r0 : 00000001
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005397f  Table: 074d4000  DAC: 00000015
Process demo (pid: 295, stack limit = 0x80d0c270)
Stack: (0x80d0def8 to 0x80d0e000)
dee0:                                                       00000228 
80310310
df00: 80332c40 80332c40 80332c44 00000001 80d0df6c 80d0df20 8007c3cc 
8008d728
df20: 00000200 00000000 80d0dfb0 00000009 fffffdff ffffffff 20000013 
80332c40
df40: 80d0c000 80d0dfb0 00095018 000f0042 000f0042 800202ec 80d0c000 
00000000
df60: 80d0df8c 80d0df70 80026540 8007c314 7edaad24 00095018 000931e4 
000f0042
df80: 00000000 80d0df90 80020254 800264d0 000931e4 0300022b 2aad5ca0 
2aad5c7c
dfa0: 2aad5c7c 00000000 7edaad24 00095018 fffffe00 2aad5ca0 2aad5c7c 
2aad5c7c
dfc0: 7edaad24 00095018 000931e4 000f0042 00000400 00070754 00000000 
00000001
dfe0: 2aad5ca0 2aad5c78 0000de6c 000089e8 20000010 0300022b 00000000 
00000000
Backtrace:
[<8008d718>] (losyscall_event+0x0/0x238) from [<8007c3cc>] 
(__ipipe_dispatch_event+0xc8/0x1a8)
[<8007c304>] (__ipipe_dispatch_event+0x0/0x1a8) from [<80026540>] 
(__ipipe_syscall_root+0x80/0x128)
[<800264c0>] (__ipipe_syscall_root+0x0/0x128) from [<80020254>] 
(vector_swi+0x74/0xb4)
  r7:000f0042 r6:000931e4 r5:00095018 r4:7edaad24
Code: 159524a8 03a00001 159536f8 13a00001 (15832000)
---[ end trace 8d00a583486ebf82 ]---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 874d4000
[00000000] *pgd=01557031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#2] PREEMPT
Modules linked in: dp
CPU: 0    Tainted: G      D     (2.6.31.8 #15)
PC is at losyscall_event+0x218/0x238
LR is at schedule+0x46c/0x50c
pc : [<8008d930>]    lr : [<8025b1ac>]    psr: a0000013
sp : 8790fef8  ip : fffffe00  fp : 8790ff1c
r10: 00000000  r9 : 803102a0  r8 : 00000018
r7 : 00000000  r6 : 8790ffb0  r5 : 88031210  r4 : 00000001
r3 : 00000000  r2 : 00b00231  r1 : 87839360  r0 : 00000001
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005397f  Table: 074d4000  DAC: 00000015
Process demo (pid: 297, stack limit = 0x8790e270)
Stack: (0x8790fef8 to 0x87910000)
fee0:                                                       00000228 
80310310
ff00: 80332c40 80332c40 80332c44 00000001 8790ff6c 8790ff20 8007c3cc 
8008d728
ff20: 00000200 00000000 8790ffb0 00000009 fffffdff ffffffff 20000013 
80332c40
ff40: 8790e000 8790ffb0 00095028 000f0042 000f0042 800202ec 8790e000 
00000000
ff60: 8790ff8c 8790ff70 80026540 8007c314 7edaad24 00095028 000931e4 
000f0042
ff80: 00000000 8790ff90 80020254 800264d0 000931e4 0300022b 2aad5ca0 
2aad5c7c
ffa0: 2aad5c7c 00000000 7edaad24 00095028 fffffe00 2aad5ca0 2aad5c7c 
2aad5c7c
ffc0: 7edaad24 00095028 000931e4 000f0042 00000400 00070754 00000000 
00000001
ffe0: 2aad5ca0 2aad5c78 0000de6c 000089e8 20000010 0300022b 00443031 
00443431
Backtrace:
[<8008d718>] (losyscall_event+0x0/0x238) from [<8007c3cc>] 
(__ipipe_dispatch_event+0xc8/0x1a8)
[<8007c304>] (__ipipe_dispatch_event+0x0/0x1a8) from [<80026540>] 
(__ipipe_syscall_root+0x80/0x128)
[<800264c0>] (__ipipe_syscall_root+0x0/0x128) from [<80020254>] 
(vector_swi+0x74/0xb4)
  r7:000f0042 r6:000931e4 r5:00095028 r4:7edaad24
Code: 159524a8 03a00001 159536f8 13a00001 (15832000)
---[ end trace 8d00a583486ebf83 ]---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
^Cpgd = 874d4000
[00000000] *pgd=01557031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#3] PREEMPT
Modules linked in: dp
CPU: 0    Tainted: G      D     (2.6.31.8 #15)
PC is at losyscall_event+0x218/0x238
LR is at schedule+0x46c/0x50c
pc : [<8008d930>]    lr : [<8025b1ac>]    psr: a0000013
sp : 80dc5ef8  ip : fffffe00  fp : 80dc5f1c
r10: 00000000  r9 : 803102a0  r8 : 00000018
r7 : 00000000  r6 : 80dc5fb0  r5 : 88031210  r4 : 00000001
r3 : 00000000  r2 : 00b00231  r1 : 87839360  r0 : 00000001
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005397f  Table: 074d4000  DAC: 00000015
Process demo (pid: 299, stack limit = 0x80dc4270)
Stack: (0x80dc5ef8 to 0x80dc6000)
5ee0:                                                       00000228 
80310310
5f00: 80332c40 80332c40 80332c44 00000001 80dc5f6c 80dc5f20 8007c3cc 
8008d728
5f20: 00000200 00000000 80dc5fb0 00000009 fffffdff ffffffff 20000013 
80332c40
5f40: 80dc4000 80dc5fb0 00095038 000f0042 000f0042 800202ec 80dc4000 
00000000
5f60: 80dc5f8c 80dc5f70 80026540 8007c314 7edaad24 00095038 000931e4 
000f0042
5f80: 00000000 80dc5f90 80020254 800264d0 000931e4 0300022b 2aad5ca0 
2aad5c7c
5fa0: 2aad5c7c 00000000 7edaad24 00095038 fffffe00 2aad5ca0 2aad5c7c 
2aad5c7c
5fc0: 7edaad24 00095038 000931e4 000f0042 00000400 00070754 00000000 
00000001
5fe0: 2aad5ca0 2aad5c78 0000de6c 000089e8 20000010 0300022b 00000000 
00000000
Backtrace:
[<8008d718>] (losyscall_event+0x0/0x238) from [<8007c3cc>] 
(__ipipe_dispatch_event+0xc8/0x1a8)
[<8007c304>] (__ipipe_dispatch_event+0x0/0x1a8) from [<80026540>] 
(__ipipe_syscall_root+0x80/0x128)
[<800264c0>] (__ipipe_syscall_root+0x0/0x128) from [<80020254>] 
(vector_swi+0x74/0xb4)
  r7:000f0042 r6:000931e4 r5:00095038 r4:7edaad24
Code: 159524a8 03a00001 159536f8 13a00001 (15832000)
---[ end trace 8d00a583486ebf84 ]---

This fault does not freeze the arm, I can countinue to work.

Ideas ?

If you can help me to adjust this problem I can start to see the gdb bug 
....

Thanks
Paolo

.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/08/2013 01:50 PM, Paolo Minazzi wrote:

> Il 07/03/2013 13.57, Gilles Chanteperdrix ha scritto:
>> On 03/07/2013 01:53 PM, Paolo Minazzi wrote:
>>
>>> Il 07/03/2013 13.38, Gilles Chanteperdrix ha scritto:
>>>> On 03/07/2013 10:08 AM, Paolo Minazzi wrote:
>>>>
>>>>> Il 06/03/2013 13.36, Gilles Chanteperdrix ha scritto:
>>>>>> On 03/06/2013 01:31 PM, Paolo Minazzi wrote:
>>>>>>
>>>>>>> Il 06/03/2013 13.06, Gilles Chanteperdrix ha scritto:
>>>>>>>> On 03/06/2013 12:40 PM, Paolo Minazzi wrote:
>>>>>>>>
>>>>>>>>> I can generate the problem only debugging with gdb, otherwise there is
>>>>>>>>> no problem.
>>>>>>>>>
>>>>>>>>> Can you help me to undertand what happen ?
>>>>>>>>> Have you got an idea ? do you need other information ?
>>>>>>>> In case it is something which was fixed since Xenomai 2.5.6, could you
>>>>>>>> try Xenomai 2.6.2.1?
>>>>>>>>
>>>>>>> I have not done the port.
>>>>>>> This work is done by an external firm.
>>>>>>> I know well enough the linux kernel, but very very little the xenomai
>>>>>>> internals.
>>>>>> You can use Xenomai 2.6.2.1 with the same version of the I-pipe kernel,
>>>>>> and the I-pipe kernel is the only thing which needs to be ported.
>>>>>>
>>>>>>> I could try ... but it is not easy ....
>>>>>> It should be as easy as:
>>>>>> - keep your kernel patched with the I-pipe patch
>>>>>> - download the newest version of Xenomai, that is 2.6.2.1
>>>>>> - follow the installation instructions, here:
>>>>>> http://www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/
>>>>>>
>>>>>>> The problem appear only using gdb .... any ideas ?
>>>>>> Could be the timer programmed for a too short delay, could be something
>>>>>> we already fixed, could be a new bug... Really, testing rapidly the last
>>>>>> version will make us win a lot of time if this is an issue already fixed.
>>>>>>
>>>>>>
>>>>> I Gilles,
>>>>> I have ported to 2.6.1 without problems.
>>>>> To 2.6.2 and 2.6.2.1 I need to add a gcc built-in. My compiler is
>>>> pass --with-atomic-ops=ad-hoc to configure script, this will avoid the
>>>> builtins.
>>>>
>>>>> gcc-4.3.2 and does not have some built-in atomic function.
>>>>> After this I need to change the switch.S because my assembler cannot
>>>> switch.S has been compiling for ages, way before gcc 4.4. Could you show
>>>> me the warning you get?
>>>>
>>>>> compile it. Maybe a newer compiler (gcc>= 4.4) could solve all these
>>>>> problems, but for me this is not a valid solution because other
>>>>> developers of us use a cygwin compiler. We should built a new cygwin
>>>>> compiler ... the libs will be different and so I will have problem with
>>>>> shared libraries .... too complex to solve a sporadic bug using gdb ....
>>>>> I can try to see the 2.6.1.
>>>> The idea of asking you to try 2.6.2.1 is not to ask you to switch to it,
>>>> but simply to do a quick test to see if you can reproduce the issue.
>>>>
>>>>
>>>     CC      drivers/xenomai/testing/switchtest.o
>>>     CC      drivers/xenomai/testing/timerbench.o
>>>     LD      drivers/xenomai/testing/xeno_timerbench.o
>>>     LD      drivers/xenomai/testing/xeno_switchtest.o
>>>     LD      drivers/xenomai/testing/built-in.o
>>>     LD      drivers/xenomai/built-in.o
>>>     LD      drivers/built-in.o
>>>     CC      arch/arm/xenomai/hal.o
>>>     AS      arch/arm/xenomai/switch.o
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:
>>> Assembler messages:
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:156:
>>> Error: bad instruction `arm( stmia ip!,{r4-sl,fp,sp,lr})'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:157:
>>> Error: bad instruction `thumb( stmia ip!,{r4-sl,fp})'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:158:
>>> Error: bad instruction `thumb( str sp,[ip],#4)'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:159:
>>> Error: bad instruction `thumb( str lr,[ip],#4)'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:170:
>>> Error: bad instruction `arm( add r4,r2,#28)'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:171:
>>> Error: bad instruction `arm( ldmia r4,{r4-sl,fp,sp,pc})'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:172:
>>> Error: bad instruction `thumb( add ip,r2,#28)'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:173:
>>> Error: bad instruction `thumb( ldmia ip!,{r4-sl,fp})'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:174:
>>> Error: bad instruction `thumb( ldr sp,[ip],#4)'
>>> /home/axel/MarvellEnv/BuildLinux/linux-2.6.31.8/arch/arm/xenomai/switch.S:175:
>>> Error: bad instruction `thumb( ldr pc,[ip])'
>>> make[2]: *** [arch/arm/xenomai/switch.o] Error 1
>>> make[1]: *** [arch/arm/xenomai] Error 2
>>> make: *** [sub-make] Error 2
>>
>> The issue is not the compiler, the issue is with the linux kernel you
>> use. Could you put me a source tarball on some ftp site?
>>
>> Please try adding:
>> #define ARM(x...)	x
>> #define	THUMB(x...)
>>
>> At the top of switch.S
>>
>>
> Hi Gill,
> 2.6.2.1 seems work ok with a normal xenomai application.
> But testing our complex application (to seach the gdb bug 
> /rt_task_sleep) I found an other small problem.
> Today I have studied this new problem that can be shown and produced 
> with a simple example.
> 
> #include <sys/mman.h>
> #include <native/task.h>
> #include <native/timer.h>
> #include <native/mutex.h>
> #include <native/sem.h>
> #include <pthread.h>
> 
> // PRIO=0 make a fault ! Other values are good
> #define PRIO 0
> 
> RT_TASK tsk;
> 
> void fn(void *arg)
> {
>          while (1)
>          {
>                  rt_task_sleep(1000000);
>          }
> }
> 
> int main(int argc, char *argv[])
> {
>          mlockall(MCL_CURRENT | MCL_FUTURE);
> 
>          rt_timer_set_mode(0);
>          rt_task_set_mode(0, 0, /* T_WARNSW , */ NULL);
> 
>          while (1)
>          {
>                  rt_task_create(&tsk, "demo", 0, PRIO, T_JOINABLE);
>                  // rt_task_start(&tsk, &fn, 0);
>                  rt_task_suspend(&tsk);
>                  rt_task_delete(&tsk);
>                  rt_task_join(&tsk);
>          }
> 
> This is the log :
> 
> / # /D/main
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = 874d4000
> [00000000] *pgd=01557031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#1] PREEMPT
> Modules linked in: dp
> CPU: 0    Not tainted  (2.6.31.8 #15)
> PC is at losyscall_event+0x218/0x238
> LR is at schedule+0x46c/0x50c
> pc : [<8008d930>]    lr : [<8025b1ac>]    psr: a0000013
> sp : 80d0def8  ip : fffffe00  fp : 80d0df1c
> r10: 00000000  r9 : 803102a0  r8 : 00000018
> r7 : 00000000  r6 : 80d0dfb0  r5 : 88031210  r4 : 00000001
> r3 : 00000000  r2 : 00b00231  r1 : 87839360  r0 : 00000001
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005397f  Table: 074d4000  DAC: 00000015
> Process demo (pid: 295, stack limit = 0x80d0c270)
> Stack: (0x80d0def8 to 0x80d0e000)
> dee0:                                                       00000228 
> 80310310
> df00: 80332c40 80332c40 80332c44 00000001 80d0df6c 80d0df20 8007c3cc 
> 8008d728
> df20: 00000200 00000000 80d0dfb0 00000009 fffffdff ffffffff 20000013 
> 80332c40
> df40: 80d0c000 80d0dfb0 00095018 000f0042 000f0042 800202ec 80d0c000 
> 00000000
> df60: 80d0df8c 80d0df70 80026540 8007c314 7edaad24 00095018 000931e4 
> 000f0042
> df80: 00000000 80d0df90 80020254 800264d0 000931e4 0300022b 2aad5ca0 
> 2aad5c7c
> dfa0: 2aad5c7c 00000000 7edaad24 00095018 fffffe00 2aad5ca0 2aad5c7c 
> 2aad5c7c
> dfc0: 7edaad24 00095018 000931e4 000f0042 00000400 00070754 00000000 
> 00000001
> dfe0: 2aad5ca0 2aad5c78 0000de6c 000089e8 20000010 0300022b 00000000 
> 00000000
> Backtrace:
> [<8008d718>] (losyscall_event+0x0/0x238) from [<8007c3cc>] 
> (__ipipe_dispatch_event+0xc8/0x1a8)
> [<8007c304>] (__ipipe_dispatch_event+0x0/0x1a8) from [<80026540>] 
> (__ipipe_syscall_root+0x80/0x128)
> [<800264c0>] (__ipipe_syscall_root+0x0/0x128) from [<80020254>] 
> (vector_swi+0x74/0xb4)
>   r7:000f0042 r6:000931e4 r5:00095018 r4:7edaad24
> Code: 159524a8 03a00001 159536f8 13a00001 (15832000)
> ---[ end trace 8d00a583486ebf82 ]---
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = 874d4000
> [00000000] *pgd=01557031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#2] PREEMPT
> Modules linked in: dp
> CPU: 0    Tainted: G      D     (2.6.31.8 #15)
> PC is at losyscall_event+0x218/0x238
> LR is at schedule+0x46c/0x50c
> pc : [<8008d930>]    lr : [<8025b1ac>]    psr: a0000013
> sp : 8790fef8  ip : fffffe00  fp : 8790ff1c
> r10: 00000000  r9 : 803102a0  r8 : 00000018
> r7 : 00000000  r6 : 8790ffb0  r5 : 88031210  r4 : 00000001
> r3 : 00000000  r2 : 00b00231  r1 : 87839360  r0 : 00000001
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005397f  Table: 074d4000  DAC: 00000015
> Process demo (pid: 297, stack limit = 0x8790e270)
> Stack: (0x8790fef8 to 0x87910000)
> fee0:                                                       00000228 
> 80310310
> ff00: 80332c40 80332c40 80332c44 00000001 8790ff6c 8790ff20 8007c3cc 
> 8008d728
> ff20: 00000200 00000000 8790ffb0 00000009 fffffdff ffffffff 20000013 
> 80332c40
> ff40: 8790e000 8790ffb0 00095028 000f0042 000f0042 800202ec 8790e000 
> 00000000
> ff60: 8790ff8c 8790ff70 80026540 8007c314 7edaad24 00095028 000931e4 
> 000f0042
> ff80: 00000000 8790ff90 80020254 800264d0 000931e4 0300022b 2aad5ca0 
> 2aad5c7c
> ffa0: 2aad5c7c 00000000 7edaad24 00095028 fffffe00 2aad5ca0 2aad5c7c 
> 2aad5c7c
> ffc0: 7edaad24 00095028 000931e4 000f0042 00000400 00070754 00000000 
> 00000001
> ffe0: 2aad5ca0 2aad5c78 0000de6c 000089e8 20000010 0300022b 00443031 
> 00443431
> Backtrace:
> [<8008d718>] (losyscall_event+0x0/0x238) from [<8007c3cc>] 
> (__ipipe_dispatch_event+0xc8/0x1a8)
> [<8007c304>] (__ipipe_dispatch_event+0x0/0x1a8) from [<80026540>] 
> (__ipipe_syscall_root+0x80/0x128)
> [<800264c0>] (__ipipe_syscall_root+0x0/0x128) from [<80020254>] 
> (vector_swi+0x74/0xb4)
>   r7:000f0042 r6:000931e4 r5:00095028 r4:7edaad24
> Code: 159524a8 03a00001 159536f8 13a00001 (15832000)
> ---[ end trace 8d00a583486ebf83 ]---
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> ^Cpgd = 874d4000
> [00000000] *pgd=01557031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#3] PREEMPT
> Modules linked in: dp
> CPU: 0    Tainted: G      D     (2.6.31.8 #15)
> PC is at losyscall_event+0x218/0x238
> LR is at schedule+0x46c/0x50c
> pc : [<8008d930>]    lr : [<8025b1ac>]    psr: a0000013
> sp : 80dc5ef8  ip : fffffe00  fp : 80dc5f1c
> r10: 00000000  r9 : 803102a0  r8 : 00000018
> r7 : 00000000  r6 : 80dc5fb0  r5 : 88031210  r4 : 00000001
> r3 : 00000000  r2 : 00b00231  r1 : 87839360  r0 : 00000001
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005397f  Table: 074d4000  DAC: 00000015
> Process demo (pid: 299, stack limit = 0x80dc4270)
> Stack: (0x80dc5ef8 to 0x80dc6000)
> 5ee0:                                                       00000228 
> 80310310
> 5f00: 80332c40 80332c40 80332c44 00000001 80dc5f6c 80dc5f20 8007c3cc 
> 8008d728
> 5f20: 00000200 00000000 80dc5fb0 00000009 fffffdff ffffffff 20000013 
> 80332c40
> 5f40: 80dc4000 80dc5fb0 00095038 000f0042 000f0042 800202ec 80dc4000 
> 00000000
> 5f60: 80dc5f8c 80dc5f70 80026540 8007c314 7edaad24 00095038 000931e4 
> 000f0042
> 5f80: 00000000 80dc5f90 80020254 800264d0 000931e4 0300022b 2aad5ca0 
> 2aad5c7c
> 5fa0: 2aad5c7c 00000000 7edaad24 00095038 fffffe00 2aad5ca0 2aad5c7c 
> 2aad5c7c
> 5fc0: 7edaad24 00095038 000931e4 000f0042 00000400 00070754 00000000 
> 00000001
> 5fe0: 2aad5ca0 2aad5c78 0000de6c 000089e8 20000010 0300022b 00000000 
> 00000000
> Backtrace:
> [<8008d718>] (losyscall_event+0x0/0x238) from [<8007c3cc>] 
> (__ipipe_dispatch_event+0xc8/0x1a8)
> [<8007c304>] (__ipipe_dispatch_event+0x0/0x1a8) from [<80026540>] 
> (__ipipe_syscall_root+0x80/0x128)
> [<800264c0>] (__ipipe_syscall_root+0x0/0x128) from [<80020254>] 
> (vector_swi+0x74/0xb4)
>   r7:000f0042 r6:000931e4 r5:00095038 r4:7edaad24
> Code: 159524a8 03a00001 159536f8 13a00001 (15832000)
> ---[ end trace 8d00a583486ebf84 ]---
> 
> This fault does not freeze the arm, I can countinue to work.
> 
> Ideas ?


Indeed, I can reproduce that. The problem seems to be calling
rt_task_delete before the task has been started. If you start the task,
this will not happen.

-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/08/2013 01:50 PM, Paolo Minazzi wrote:

> This fault does not freeze the arm, I can countinue to work.
> 
> Ideas ?


Please try the following patch:

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index c91a6f3..ed3864b 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
 	rpi_pop(thread);
 
 	sys_ppd = xnsys_ppd_get(0);
-	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
-	thread->u_mode = NULL;
+	if (thread->u_mode) {
+		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
+		thread->u_mode = NULL;
+	}
 
 	xnarch_atomic_dec(&sys_ppd->refcnt);
 
@@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
       ret_handled:
 
 	/* Update the userland-visible state. */
-	if (thread)
+	if (thread && thread->u_mode)
 		*thread->u_mode = thread->state;
 
 	trace_mark(xn_nucleus, syscall_histage_exit,
@@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
       ret_handled:
 
 	/* Update the userland-visible state. */
-	if (thread)
+	if (thread && thread->u_mode)
 		*thread->u_mode = thread->state;
 
 	trace_mark(xn_nucleus, syscall_lostage_exit,

-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/11/2013 09:47 AM, Paolo Minazzi wrote:

> Il 08/03/2013 21.13, Gilles Chanteperdrix ha scritto:
>> On 03/08/2013 01:50 PM, Paolo Minazzi wrote:
>>
>>> This fault does not freeze the arm, I can countinue to work.
>>>
>>> Ideas ?
>>
>> Please try the following patch:
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index c91a6f3..ed3864b 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/nucleus/shadow.c
>> @@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
>>   	rpi_pop(thread);
>>
>>   	sys_ppd = xnsys_ppd_get(0);
>> -	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>> -	thread->u_mode = NULL;
>> +	if (thread->u_mode) {
>> +		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>> +		thread->u_mode = NULL;
>> +	}
>>
>>   	xnarch_atomic_dec(&sys_ppd->refcnt);
>>
>> @@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>         ret_handled:
>>
>>   	/* Update the userland-visible state. */
>> -	if (thread)
>> +	if (thread&&  thread->u_mode)
>>   		*thread->u_mode = thread->state;
>>
>>   	trace_mark(xn_nucleus, syscall_histage_exit,
>> @@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>         ret_handled:
>>
>>   	/* Update the userland-visible state. */
>> -	if (thread)
>> +	if (thread&&  thread->u_mode)
>>   		*thread->u_mode = thread->state;
>>
>>   	trace_mark(xn_nucleus, syscall_lostage_exit,
>>
> Hi Gilles,
> I can see the same problem under 2.6.2.1.
> I was debugging, after a while I could not stop anymore the code using 
> breakpoints because all tasks are stopped at rt_task_sleep.
> After this, If I close the application and restart it, the rt_task sleep 
> are blocked. I have to restart my arm processor.
> Any ideas ?


Debugging xenomai thread causes the timers to be stopped, and they are
supposed to be restarted when the thread blocked on the breakpoint,
maybe this is what goes wrong: the timers are not restarted.

Another possibility is the hardware timer being programmed for a too
short delay.

Please no private mails.

> Paolo
> 
> 



-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Paolo Minazzi]

Il 11/03/2013 14.07, Gilles Chanteperdrix ha scritto:
> On 03/11/2013 09:47 AM, Paolo Minazzi wrote:
>
>> Il 08/03/2013 21.13, Gilles Chanteperdrix ha scritto:
>>> On 03/08/2013 01:50 PM, Paolo Minazzi wrote:
>>>
>>>> This fault does not freeze the arm, I can countinue to work.
>>>>
>>>> Ideas ?
>>> Please try the following patch:
>>>
>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>>> index c91a6f3..ed3864b 100644
>>> --- a/ksrc/nucleus/shadow.c
>>> +++ b/ksrc/nucleus/shadow.c
>>> @@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
>>>    	rpi_pop(thread);
>>>
>>>    	sys_ppd = xnsys_ppd_get(0);
>>> -	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>> -	thread->u_mode = NULL;
>>> +	if (thread->u_mode) {
>>> +		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>> +		thread->u_mode = NULL;
>>> +	}
>>>
>>>    	xnarch_atomic_dec(&sys_ppd->refcnt);
>>>
>>> @@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>          ret_handled:
>>>
>>>    	/* Update the userland-visible state. */
>>> -	if (thread)
>>> +	if (thread&&   thread->u_mode)
>>>    		*thread->u_mode = thread->state;
>>>
>>>    	trace_mark(xn_nucleus, syscall_histage_exit,
>>> @@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>          ret_handled:
>>>
>>>    	/* Update the userland-visible state. */
>>> -	if (thread)
>>> +	if (thread&&   thread->u_mode)
>>>    		*thread->u_mode = thread->state;
>>>
>>>    	trace_mark(xn_nucleus, syscall_lostage_exit,
>>>
>> Hi Gilles,
>> I can see the same problem under 2.6.2.1.
>> I was debugging, after a while I could not stop anymore the code using
>> breakpoints because all tasks are stopped at rt_task_sleep.
>> After this, If I close the application and restart it, the rt_task sleep
>> are blocked. I have to restart my arm processor.
>> Any ideas ?
>
> Debugging xenomai thread causes the timers to be stopped, and they are
> supposed to be restarted when the thread blocked on the breakpoint,
> maybe this is what goes wrong: the timers are not restarted.
>
> Another possibility is the hardware timer being programmed for a too
> short delay.
>
> Please no private mails.
>
>> Paolo
>>
>>
>
>

Time ago I have already tried to change a parameter 
ksrc/nucleus/timer.c:402 (the following is the comment ...)
                                 /*
                                  * Make the blocked timer elapse again
                                  * at a reasonably close date in the
                                  * future, waiting for the timebase to
                                  * be unlocked at some point. Timers
                                  * are blocked when single-stepping
                                  * into an application using a
                                  * debugger, so it is fine to wait for
                                  * 250 ms for the user to continue
                                  * program execution.
                                  */
                                 interval = xnarch_ns_to_tsc(250000000ULL);
                                 goto requeue;

I have tried bigger and smaller value than 250ms without luck.
If you have got some ideas I can make tests as you want.
Regards,
Paolo

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/11/2013 02:46 PM, Paolo Minazzi wrote:

> Il 11/03/2013 14.07, Gilles Chanteperdrix ha scritto:
>> On 03/11/2013 09:47 AM, Paolo Minazzi wrote:
>>
>>> Il 08/03/2013 21.13, Gilles Chanteperdrix ha scritto:
>>>> On 03/08/2013 01:50 PM, Paolo Minazzi wrote:
>>>>
>>>>> This fault does not freeze the arm, I can countinue to work.
>>>>>
>>>>> Ideas ?
>>>> Please try the following patch:
>>>>
>>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>>>> index c91a6f3..ed3864b 100644
>>>> --- a/ksrc/nucleus/shadow.c
>>>> +++ b/ksrc/nucleus/shadow.c
>>>> @@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
>>>>    	rpi_pop(thread);
>>>>
>>>>    	sys_ppd = xnsys_ppd_get(0);
>>>> -	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>> -	thread->u_mode = NULL;
>>>> +	if (thread->u_mode) {
>>>> +		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>> +		thread->u_mode = NULL;
>>>> +	}
>>>>
>>>>    	xnarch_atomic_dec(&sys_ppd->refcnt);
>>>>
>>>> @@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>          ret_handled:
>>>>
>>>>    	/* Update the userland-visible state. */
>>>> -	if (thread)
>>>> +	if (thread&&   thread->u_mode)
>>>>    		*thread->u_mode = thread->state;
>>>>
>>>>    	trace_mark(xn_nucleus, syscall_histage_exit,
>>>> @@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>          ret_handled:
>>>>
>>>>    	/* Update the userland-visible state. */
>>>> -	if (thread)
>>>> +	if (thread&&   thread->u_mode)
>>>>    		*thread->u_mode = thread->state;
>>>>
>>>>    	trace_mark(xn_nucleus, syscall_lostage_exit,
>>>>
>>> Hi Gilles,
>>> I can see the same problem under 2.6.2.1.
>>> I was debugging, after a while I could not stop anymore the code using
>>> breakpoints because all tasks are stopped at rt_task_sleep.
>>> After this, If I close the application and restart it, the rt_task sleep
>>> are blocked. I have to restart my arm processor.
>>> Any ideas ?
>>
>> Debugging xenomai thread causes the timers to be stopped, and they are
>> supposed to be restarted when the thread blocked on the breakpoint,
>> maybe this is what goes wrong: the timers are not restarted.
>>
>> Another possibility is the hardware timer being programmed for a too
>> short delay.
>>
>> Please no private mails.
>>
>>> Paolo
>>>
>>>
>>
>>
> 
> Time ago I have already tried to change a parameter 
> ksrc/nucleus/timer.c:402 (the following is the comment ...)
>                                  /*
>                                   * Make the blocked timer elapse again
>                                   * at a reasonably close date in the
>                                   * future, waiting for the timebase to
>                                   * be unlocked at some point. Timers
>                                   * are blocked when single-stepping
>                                   * into an application using a
>                                   * debugger, so it is fine to wait for
>                                   * 250 ms for the user to continue
>                                   * program execution.
>                                   */
>                                  interval = xnarch_ns_to_tsc(250000000ULL);
>                                  goto requeue;
> 
> I have tried bigger and smaller value than 250ms without luck.


As the comment says, and the code shows, the timer will elapse again and
check if the timebase is unlocked, if the timebase is locked, it will go
to sleep again.

> If you have got some ideas I can make tests as you want.


Provide us with an example allowing to reproduce the issue. Or
alternatively, you can do the debug yourself following the leads I
already gave you.


-- 
                                                                Gilles.

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Paolo Minazzi]

Il 11/03/2013 21.26, Gilles Chanteperdrix ha scritto:
> On 03/11/2013 02:46 PM, Paolo Minazzi wrote:
>
>> Il 11/03/2013 14.07, Gilles Chanteperdrix ha scritto:
>>> On 03/11/2013 09:47 AM, Paolo Minazzi wrote:
>>>
>>>> Il 08/03/2013 21.13, Gilles Chanteperdrix ha scritto:
>>>>> On 03/08/2013 01:50 PM, Paolo Minazzi wrote:
>>>>>
>>>>>> This fault does not freeze the arm, I can countinue to work.
>>>>>>
>>>>>> Ideas ?
>>>>> Please try the following patch:
>>>>>
>>>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>>>>> index c91a6f3..ed3864b 100644
>>>>> --- a/ksrc/nucleus/shadow.c
>>>>> +++ b/ksrc/nucleus/shadow.c
>>>>> @@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
>>>>>     	rpi_pop(thread);
>>>>>
>>>>>     	sys_ppd = xnsys_ppd_get(0);
>>>>> -	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>>> -	thread->u_mode = NULL;
>>>>> +	if (thread->u_mode) {
>>>>> +		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>>> +		thread->u_mode = NULL;
>>>>> +	}
>>>>>
>>>>>     	xnarch_atomic_dec(&sys_ppd->refcnt);
>>>>>
>>>>> @@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>>           ret_handled:
>>>>>
>>>>>     	/* Update the userland-visible state. */
>>>>> -	if (thread)
>>>>> +	if (thread&&    thread->u_mode)
>>>>>     		*thread->u_mode = thread->state;
>>>>>
>>>>>     	trace_mark(xn_nucleus, syscall_histage_exit,
>>>>> @@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>>           ret_handled:
>>>>>
>>>>>     	/* Update the userland-visible state. */
>>>>> -	if (thread)
>>>>> +	if (thread&&    thread->u_mode)
>>>>>     		*thread->u_mode = thread->state;
>>>>>
>>>>>     	trace_mark(xn_nucleus, syscall_lostage_exit,
>>>>>
>>>> Hi Gilles,
>>>> I can see the same problem under 2.6.2.1.
>>>> I was debugging, after a while I could not stop anymore the code using
>>>> breakpoints because all tasks are stopped at rt_task_sleep.
>>>> After this, If I close the application and restart it, the rt_task sleep
>>>> are blocked. I have to restart my arm processor.
>>>> Any ideas ?
>>> Debugging xenomai thread causes the timers to be stopped, and they are
>>> supposed to be restarted when the thread blocked on the breakpoint,
>>> maybe this is what goes wrong: the timers are not restarted.
>>>
>>> Another possibility is the hardware timer being programmed for a too
>>> short delay.
>>>
>>> Please no private mails.
>>>
>>>> Paolo
>>>>
>>>>
>>>
>> Time ago I have already tried to change a parameter
>> ksrc/nucleus/timer.c:402 (the following is the comment ...)
>>                                   /*
>>                                    * Make the blocked timer elapse again
>>                                    * at a reasonably close date in the
>>                                    * future, waiting for the timebase to
>>                                    * be unlocked at some point. Timers
>>                                    * are blocked when single-stepping
>>                                    * into an application using a
>>                                    * debugger, so it is fine to wait for
>>                                    * 250 ms for the user to continue
>>                                    * program execution.
>>                                    */
>>                                   interval = xnarch_ns_to_tsc(250000000ULL);
>>                                   goto requeue;
>>
>> I have tried bigger and smaller value than 250ms without luck.
>
> As the comment says, and the code shows, the timer will elapse again and
> check if the timebase is unlocked, if the timebase is locked, it will go
> to sleep again.
>
>> If you have got some ideas I can make tests as you want.
>
> Provide us with an example allowing to reproduce the issue. Or
> alternatively, you can do the debug yourself following the leads I
> already gave you.
>
>
Unfortunately it is not easy make a small program that produce the problem.
I have tried making the debugging with gdb an automatic process, but I 
cannot see the problem.
I can uderstand that timer stops because a problem in programming the 
timer interval.
But I do not understand why if I use CTRL-C to stop the application (in 
a moment that rt_task_sleep are blocked) I have still the same problem 
(rt_task_sleep blocked). The only solution to use a realtime process is 
to reset my arm processor. Why xenomai does not reset all when I start a 
xenomai application ?

Paolo

Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Gilles Chanteperdrix]

On 03/12/2013 11:19 AM, Paolo Minazzi wrote:

> Il 11/03/2013 21.26, Gilles Chanteperdrix ha scritto:
>> On 03/11/2013 02:46 PM, Paolo Minazzi wrote:
>>
>>> Il 11/03/2013 14.07, Gilles Chanteperdrix ha scritto:
>>>> On 03/11/2013 09:47 AM, Paolo Minazzi wrote:
>>>>
>>>>> Il 08/03/2013 21.13, Gilles Chanteperdrix ha scritto:
>>>>>> On 03/08/2013 01:50 PM, Paolo Minazzi wrote:
>>>>>>
>>>>>>> This fault does not freeze the arm, I can countinue to work.
>>>>>>>
>>>>>>> Ideas ?
>>>>>> Please try the following patch:
>>>>>>
>>>>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>>>>>> index c91a6f3..ed3864b 100644
>>>>>> --- a/ksrc/nucleus/shadow.c
>>>>>> +++ b/ksrc/nucleus/shadow.c
>>>>>> @@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
>>>>>>     	rpi_pop(thread);
>>>>>>
>>>>>>     	sys_ppd = xnsys_ppd_get(0);
>>>>>> -	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>>>> -	thread->u_mode = NULL;
>>>>>> +	if (thread->u_mode) {
>>>>>> +		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>>>> +		thread->u_mode = NULL;
>>>>>> +	}
>>>>>>
>>>>>>     	xnarch_atomic_dec(&sys_ppd->refcnt);
>>>>>>
>>>>>> @@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>>>           ret_handled:
>>>>>>
>>>>>>     	/* Update the userland-visible state. */
>>>>>> -	if (thread)
>>>>>> +	if (thread&&    thread->u_mode)
>>>>>>     		*thread->u_mode = thread->state;
>>>>>>
>>>>>>     	trace_mark(xn_nucleus, syscall_histage_exit,
>>>>>> @@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>>>           ret_handled:
>>>>>>
>>>>>>     	/* Update the userland-visible state. */
>>>>>> -	if (thread)
>>>>>> +	if (thread&&    thread->u_mode)
>>>>>>     		*thread->u_mode = thread->state;
>>>>>>
>>>>>>     	trace_mark(xn_nucleus, syscall_lostage_exit,
>>>>>>
>>>>> Hi Gilles,
>>>>> I can see the same problem under 2.6.2.1.
>>>>> I was debugging, after a while I could not stop anymore the code using
>>>>> breakpoints because all tasks are stopped at rt_task_sleep.
>>>>> After this, If I close the application and restart it, the rt_task sleep
>>>>> are blocked. I have to restart my arm processor.
>>>>> Any ideas ?
>>>> Debugging xenomai thread causes the timers to be stopped, and they are
>>>> supposed to be restarted when the thread blocked on the breakpoint,
>>>> maybe this is what goes wrong: the timers are not restarted.
>>>>
>>>> Another possibility is the hardware timer being programmed for a too
>>>> short delay.
>>>>
>>>> Please no private mails.
>>>>
>>>>> Paolo
>>>>>
>>>>>
>>>>
>>> Time ago I have already tried to change a parameter
>>> ksrc/nucleus/timer.c:402 (the following is the comment ...)
>>>                                   /*
>>>                                    * Make the blocked timer elapse again
>>>                                    * at a reasonably close date in the
>>>                                    * future, waiting for the timebase to
>>>                                    * be unlocked at some point. Timers
>>>                                    * are blocked when single-stepping
>>>                                    * into an application using a
>>>                                    * debugger, so it is fine to wait for
>>>                                    * 250 ms for the user to continue
>>>                                    * program execution.
>>>                                    */
>>>                                   interval = xnarch_ns_to_tsc(250000000ULL);
>>>                                   goto requeue;
>>>
>>> I have tried bigger and smaller value than 250ms without luck.
>>
>> As the comment says, and the code shows, the timer will elapse again and
>> check if the timebase is unlocked, if the timebase is locked, it will go
>> to sleep again.
>>
>>> If you have got some ideas I can make tests as you want.
>>
>> Provide us with an example allowing to reproduce the issue. Or
>> alternatively, you can do the debug yourself following the leads I
>> already gave you.
>>
>>
> Unfortunately it is not easy make a small program that produce the problem.
> I have tried making the debugging with gdb an automatic process, but I 
> cannot see the problem.
> I can uderstand that timer stops because a problem in programming the 
> timer interval.
> But I do not understand why if I use CTRL-C to stop the application (in 
> a moment that rt_task_sleep are blocked) I have still the same problem 
> (rt_task_sleep blocked). The only solution to use a realtime process is 
> to reset my arm processor. Why xenomai does not reset all when I start a 
> xenomai application ?


Well, there is a bug. If the code did the right thing, there would be no
bug, right? Now your job is to find it. We can not find it for you if
you do not provide us with a way to reproduce it.

-- 
                                                                Gilles.