[Xenomai-core] rt_task_create() hangs ?

[Xenomai-core] rt_task_create() hangs ?

[Steven Scholz]

Hi all,

we're doing the first steps with Xenomai and stumbled about some problems.

On our AT91RM9200 (adeos-ipipe-2.6.14-arm-1.5-04,
ipipe-2.6.14-at91-1.5-04.patch) a simple application (that just creates and
destroys two threads)

	rt_task_create(&task_1,"task_1",0,50,0);
	rt_task_create(&task_2,"task_2",0,51,0);
	...
	rt_task_delete(&task_2);
	rt_task_delete(&task_1);

runs fine when started for the first time. But when started again it hangs
in the rt_task_create() for the second task.
Funny enough it all runs fine when we first delete task1 and then task2 ...

On an x86 (adeos-ipipe-2.6.19-i386-1.6-03) the application runs fine. Either
way.

We noticed that on the AT91RM9200 we don't see the

Xenomai: POSIX: destroyed thread c14a0320

message. Not even when running (and stopping) cyclictest. I suspect that
this is leading to our problems.

Any idea?

Thanks a million!

--
Steven

Re: [Xenomai-core] rt_task_create() hangs ?

[Philippe Gerum]

On Wed, 2007-01-24 at 14:32 +0100, Steven Scholz wrote:
> Hi all,
> 
> we're doing the first steps with Xenomai and stumbled about some problems.
> 
> On our AT91RM9200 (adeos-ipipe-2.6.14-arm-1.5-04,
> ipipe-2.6.14-at91-1.5-04.patch) a simple application (that just creates and
> destroys two threads)
> 
> 	rt_task_create(&task_1,"task_1",0,50,0);
> 	rt_task_create(&task_2,"task_2",0,51,0);
> 	...
> 	rt_task_delete(&task_2);
> 	rt_task_delete(&task_1);
> 
> runs fine when started for the first time. But when started again it hangs
> in the rt_task_create() for the second task.
> Funny enough it all runs fine when we first delete task1 and then task2 ...
> 

Could you post the full source of your test app? It's impossible to
infere anything from this description without understanding who actually
does what in your app. TIA.

> On an x86 (adeos-ipipe-2.6.19-i386-1.6-03) the application runs fine. Either
> way.
> 
> We noticed that on the AT91RM9200 we don't see the
> 
> Xenomai: POSIX: destroyed thread c14a0320
> 
> message. Not even when running (and stopping) cyclictest. I suspect that
> this is leading to our problems.
> 

This message is not issued by the native Xenomai API, but by the POSIX
one, so those issues are not necessarily related.

> Any idea?
> 
> Thanks a million!
> 
> --
> Steven
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] rt_task_create() hangs ?

[Gilles Chanteperdrix]

Steven Scholz wrote:
> We noticed that on the AT91RM9200 we don't see the
> 
> Xenomai: POSIX: destroyed thread c14a0320
> 
> message. Not even when running (and stopping) cyclictest. I suspect that
> this is leading to our problems.

This message only appears if CONFIG_XENO_OPT_DEBUG_POSIX is enabled, are
you sure it is enabled in the AT91 kernel configuration ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] rt_task_create() hangs ?

[Steven Scholz]

Hi all,

I wrote:

> On our AT91RM9200 (adeos-ipipe-2.6.14-arm-1.5-04,
> ipipe-2.6.14-at91-1.5-04.patch) a simple application (that just creates and
> destroys two threads)
> 
> 	rt_task_create(&task_1,"task_1",0,50,0);
> 	rt_task_create(&task_2,"task_2",0,51,0);
> 	...
> 	rt_task_delete(&task_2);
> 	rt_task_delete(&task_1);
> 
> runs fine when started for the first time. But when started again it hangs
> in the rt_task_create() for the second task.
> Funny enough it all runs fine when we first delete task1 and then task2 ...
> 
> On an x86 (adeos-ipipe-2.6.19-i386-1.6-03) the application runs fine. Either
> way.
> 
> We noticed that on the AT91RM9200 we don't see the
> 
> Xenomai: POSIX: destroyed thread c14a0320
> 
> message. Not even when running (and stopping) cyclictest. I suspect that
> this is leading to our problems.

I now tested Gille's brand new adeos-ipipe-2.6.19-arm-1.6-01.patch. The
above problems disapeared. I even do see a "Xenomai: POSIX: destroyed
thread" now.

So is this a known bug of ipipe-1.5 vs ipipe-1.6?
Or does anyone remember a bug like that?

Thanks,

Steven

Re: [Xenomai-core] rt_task_create() hangs ?

[Gilles Chanteperdrix]

Steven Scholz wrote:
> Hi all,
> 
> I wrote:
> 
> 
>>On our AT91RM9200 (adeos-ipipe-2.6.14-arm-1.5-04,
>>ipipe-2.6.14-at91-1.5-04.patch) a simple application (that just creates and
>>destroys two threads)
>>
>>	rt_task_create(&task_1,"task_1",0,50,0);
>>	rt_task_create(&task_2,"task_2",0,51,0);
>>	...
>>	rt_task_delete(&task_2);
>>	rt_task_delete(&task_1);
>>
>>runs fine when started for the first time. But when started again it hangs
>>in the rt_task_create() for the second task.
>>Funny enough it all runs fine when we first delete task1 and then task2 ...
>>
>>On an x86 (adeos-ipipe-2.6.19-i386-1.6-03) the application runs fine. Either
>>way.
>>
>>We noticed that on the AT91RM9200 we don't see the
>>
>>Xenomai: POSIX: destroyed thread c14a0320
>>
>>message. Not even when running (and stopping) cyclictest. I suspect that
>>this is leading to our problems.
> 
> 
> I now tested Gille's brand new adeos-ipipe-2.6.19-arm-1.6-01.patch. The
> above problems disapeared. I even do see a "Xenomai: POSIX: destroyed
> thread" now.
> 
> So is this a known bug of ipipe-1.5 vs ipipe-1.6?
> Or does anyone remember a bug like that?

I do not think there is such a known bug. There were some recent fixes
in the native skin, but as far as I remember they were for anonymous
objects. In any case, as Philippe already told you, it is hard to say
anything without seeing any code. As for the posix skin messages about
objects destruction, they only appear if an option is selected in the
kernel configuration. Are you sure this option was enabled when you did
not see the messages ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] rt_task_create() hangs ?

[Steven Scholz]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hi Gilles,

>> I now tested Gille's brand new adeos-ipipe-2.6.19-arm-1.6-01.patch. The
>> above problems disapeared. I even do see a "Xenomai: POSIX: destroyed
>> thread" now.
>>
>> So is this a known bug of ipipe-1.5 vs ipipe-1.6?
>> Or does anyone remember a bug like that?
> 
> I do not think there is such a known bug. There were some recent fixes
> in the native skin, but as far as I remember they were for anonymous
> objects. In any case, as Philippe already told you, it is hard to say
> anything without seeing any code. 
Did he? I never saw that mail. :-(
However I attach the file that hangs when starting it for the second time.

PLEASE NOTE: I just found that the programm runs fine again and again even
under 2.6.14 iff I deselect CONFIG_XENO_HW_FPU. With CONFIG_XENO_HW_FPU=y it
will hang...

So I am now suspecting that it would hang with your new
adeos-ipipe-2.6.19-arm-1.6-01.patch as well...
Problem is: I can only compile your patch with FPU disabled! Otehrwise he
complains about a missing fp_init() !!!

BTW: Is CONFIG_XENO_HW_FPU intended for HW floating point support!? Or for
floating point emulation done by the kernel? NWFPE? Are there actually ARM
cpus with HW FPU?

> As for the posix skin messages about
> objects destruction, they only appear if an option is selected in the
> kernel configuration. Are you sure this option was enabled when you did
> not see the messages ?
Yes I am.

-- 
Steven

[-- Attachment #2: threadtest1.c --]
[-- Type: text/plain, Size: 1384 bytes --]


#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/mman.h>

#include <native/task.h>


#define STATE_TASK_1_CREATED       1
#define STATE_TASK_2_CREATED       2

unsigned int my_state = 0;

RT_TASK  task_1;
RT_TASK  task_2;

/* .................................................................................... */


void cleanup_all(void) {


  if (my_state & STATE_TASK_2_CREATED) {
    printf("delete task_2\n");
    rt_task_delete(&task_2);
    my_state &= ~STATE_TASK_2_CREATED;
  }

  if (my_state & STATE_TASK_1_CREATED) {
    printf("delete task_1\n");
    rt_task_delete(&task_1);
    my_state &= ~STATE_TASK_1_CREATED;
  }

}


/* .................................................................................... */

int main(int argc, char* argv[]) {
  int ret = 0;

  /* no memory-swapping for this programm */
  mlockall(MCL_CURRENT | MCL_FUTURE);


  /* create task_1 */
  ret = rt_task_create(&task_1,"task_1",0,50,0);
  if (ret) {
    printf("failed to create task_1, code %d\n",ret);
    goto error;
  }
  my_state |= STATE_TASK_1_CREATED;
  printf("created task_1\n");



  /* create task_2 */
  ret = rt_task_create(&task_2,"task_2",0,51,0);
  if (ret) {
    printf("failed to create task_2, code %d\n",ret);
    goto error;
  }
  my_state |= STATE_TASK_2_CREATED;
  printf("created task_2\n");

error:
  cleanup_all();
  return ret;
}

Re: [Xenomai-core] rt_task_create() hangs ?

[Gilles Chanteperdrix]

Steven Scholz wrote:
> Hi Gilles,
> 
> 
>>>I now tested Gille's brand new adeos-ipipe-2.6.19-arm-1.6-01.patch. The
>>>above problems disapeared. I even do see a "Xenomai: POSIX: destroyed
>>>thread" now.
>>>
>>>So is this a known bug of ipipe-1.5 vs ipipe-1.6?
>>>Or does anyone remember a bug like that?
>>
>>I do not think there is such a known bug. There were some recent fixes
>>in the native skin, but as far as I remember they were for anonymous
>>objects. In any case, as Philippe already told you, it is hard to say
>>anything without seeing any code. 
> 
> Did he? I never saw that mail. :-(
> However I attach the file that hangs when starting it for the second time.
> 
> PLEASE NOTE: I just found that the programm runs fine again and again even
> under 2.6.14 iff I deselect CONFIG_XENO_HW_FPU. With CONFIG_XENO_HW_FPU=y it
> will hang...
> 
> So I am now suspecting that it would hang with your new
> adeos-ipipe-2.6.19-arm-1.6-01.patch as well...
> Problem is: I can only compile your patch with FPU disabled! Otehrwise he
> complains about a missing fp_init() !!!

I have tried several compilations with Xenomai FPU and kernel FPU
emulation enabled, they all compile fine here. Could you send me your
.config ?

-- 
                                                 Gilles Chanteperdrix