[Xenomai-help] Kernel OOps large appl.

Tue, 31 Oct 2006 05:48:35 -0800

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:
 
Oops: kernel access of bad area, sig: 11
NIP: C0012A00 XER: 20000000 LR: C00129DC SP: C9589E30 REGS: c9589d80 TRAP: 0300    Not tainted
Using defaults from ksymoops -t elf32-powerpc -a powerpc:common
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c9588000[294] 'ApplicationExe' Last syscall: 285344299
last math c8020000 last altivec 00000000
GPR00: C00129DC C9589E30 C9588000 FFFFFFFF C0008878 C01F82C0 C9587FFF C01FCF48
GPR08: 003C62E0 C01FCF40 6C800000 CDE86268 00000000 1001A288 00000000 00000000
GPR16: 00000000 00000000 C0200000 C0240000 C0210000 C0200000 C0200000 C0210000
GPR24: 00000001 C0230000 C0260000 C0222420 CFE50000 00000000 00000000 C9589E30
Call backtrace:
C00129DC C011FB94 C0120F18 C0025FBC C000D638 C0005A3C 0FFD9F80
0FC4B888 0FC4B750 0FC0CF40 0FFD890C 0FF68FC0 0EE6C9A0
Warning (Oops_read): Code line not seen, dumping what data is available
 

>>NIP; c0012a00 <schedule+2a4/574>   <=====
 
>>GPR0; c00129dc <schedule+280/574>
>>GPR4; c0008878 <_switch_to+5c/90>
>>GPR5; c01f82c0 <init_signals+3d4/504>
>>GPR7; c01fcf48 <ipipe_root+1008/2dc0>
>>GPR9; c01fcf40 <ipipe_root+1000/2dc0>
>>GPR18; c0200000 <pid_base_dentry_operations+4/18>
>>GPR19; c0240000 <read_buffers+b20/8000>
>>GPR20; c0210000 <__ksymtab_get_buffer_flushtime+0/8>
>>GPR21; c0200000 <pid_base_dentry_operations+4/18>
>>GPR22; c0200000 <pid_base_dentry_operations+4/18>
>>GPR23; c0210000 <__ksymtab_get_buffer_flushtime+0/8>
>>GPR25; c0230000 <exec_domains_lock+394/400>
>>GPR26; c0260000 <xnpipe_states+1630/9600>
>>GPR27; c0222420 <rtcan_init+4/4c>
 
Trace; c00129dc <schedule+280/574>
Trace; c011fb94 <xnshadow_ppd_lookup_inner+12c/1d4>
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().
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.
 
 
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 ?
 
Any ideas ?
 
 
Regards,
 
Daniel.
 
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to