Re: [Xenomai-help] Kernel OOps large appl.

[Philippe Gerum <rpm@xenomai.org>]

On Tue, 2006-10-31 at 13:25 +0000, Daniel Schnell wrote:
> Hi,
>  
> we are porting our application to the POSIX skin of Xenomai. We are
> using a 2.4.25 Denx based Kernel with 4 days old Xenomai 2.3-devel svn
> trunk on a MPC5200B based custom board. The application spawns 36
> Threads, uses 265 mutexes and 22 condition variables. We increased all
> numbers that can be set inside Xenomai kernel config to 10x, just to
> be sure we are not blowing out Kernel limits (Prinzip: Stange im
> Nebel).
>  
>  
> The following output of ksymoops will be done for the occuring oops:
>  
[...]
> Trace; c00129dc <schedule+280/574>
> Trace; c011fb94 <xnshadow_ppd_lookup_inner+12c/1d4>

This backtrace looks weird.

> Trace; c0120f18 <xnshadow_sys_bind+298/300>
> Trace; c0025fbc <__ipipe_dispatch_event+b4/198>
> Trace; c000d638 <__ipipe_syscall_root+44/e0>
> Trace; c0005a3c <DoSyscall+1c/90>
> Trace; 0ffd9f80 Before first symbol
> Trace; 0fc4b888 Before first symbol
> Trace; 0fc4b750 Before first symbol
> Trace; 0fc0cf40 Before first symbol
> Trace; 0ffd890c Before first symbol
> Trace; 0ff68fc0 Before first symbol
> Trace; 0ee6c9a0 Before first symbol
>  
>  
>  
> The call right before entering the system space traced down with a
> running gdb is __wrap_clock_nanosleep().

This means that you are linking your application with the POSIX skin
too. So your setup is UVM/psos library + POSIX skin support?
Please send your Makefile, this should help understanding what's bound
to your application.

> It always happens here. But when just testing this function alone in a
> cycle, no kernel oops happens. The oops seems to be a correlation of
> different events.

The stack trace does not even match the wrapped nanosleep syscall, so
there is some strange interactions ongoing between the interfaces used.

>  
>  
> On the other side we have a constant problem with clock_nanosleep() in
> that it always returns after 1/4 of the supposed time.
>  
> I.e. calling
>  
> struct timespec t
> t.tv_sec = 5; t.tv_nsec = 0;
> clock_nanosleep(CLOCK_REALTIME, 0, &t, NULL);
>  
> returns after 1 second and not 4.
>  
> Whereas clock_gettime(CLOCK_REALTIME, &t) works correctly (i.e. the
> difference of two timestamps taken before and after clock_nanosleep()
> with the above settings results in a diff time of 1 sec). So somehow
> the external hardware timer setup is incorrect or maybe frequencies ?

The setup for a lite5200 hw on a Denx 2.4.25 kernel should work out of
the box. This is much more likely a software issue, maybe related to the
strangenesses above.

>  
> Any ideas ?
>  
>  
> Regards,
>  
> Daniel.
>  
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.