[Xenomai-help] Re: Re: Re: Re: A fairly small rtnet/Xenomai

[Philippe Gerum <rpm@xenomai.org>]

On Thu, 2006-12-21 at 14:36 +0100, M. Koehrer wrote:
> Hi all,
> 
> some more interesing measurements:
> 1) Even when I remove the printf() completely, the system freezes.
> My realtimetask is then
> static void realtimetask(void *arg)
> {
>     system("ls -l");
>     rt_task_sleep(1000000000ULL);
> 
> }
> 
> 2) When I replace the printf() by a gepid() the behaviour is the same.
> 
> 3) Jan, your application using the rt_task_shadow behaves the very same (it freezes)!
> 
> 4) A getpid() directly after system does not help - however, a printf at this position helps to
> prevent the freeze.
> 
> But now, I found one very interesting thing:
> When I rename my /lib/tls to /lib/tls.disabled, it works!!!!
> It seems to be (once more) a ugly thread local storage stuff.
> The ldd dependency of xeno_crash show libc and libpthread that are take from 
> /lib/tls/i686/cmov directory.
> Perhaps that could give a hint!

Please check the following assertions on your setup:

- does enabling the debug option for the Xenomai nucleus cause Xenomai
warnings to appear (messages about forced switches of the crashtest task
to secondary mode), even over 2.6.17 with the very same test code?

- does enabling CONFIG_DEBUG_SPINLOCK and CONFIG_DEBUG_SPINLOCK_SLEEP in
the kernel hacking section cause Linux warnings to appear while the test
code runs over 2.6.19, before the box crashes?

- does the bug still occurs after the call to the system() routine has
been replaced by the following frag?

    if (vfork() == 0)
            execlp("/bin/ls", "ls", "-l", NULL);
    else
            wait(NULL);

-- 
Philippe.