>> >
>> > Anyway, is not it simply a deadlock in your application ?
>>
>> I don't think so. Here is a list of all tasks:
>>
>> ~ # cat /proc/xenomai/stat
>> CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
>>   0  0      0          7452       0     00500080   98.9  ROOT
>>   0  83     196        196        0     00300380    0.0  DOS4
>>   0  81     13         13         0     00300380    0.0  DOS5
>>   0  97     618        830        0     00300380    0.0  @WDG
>>   0  101    751        1127       0     00300380    0.0  HSSR
>>   0  128    1268       2186       0     00300380    0.0  DOS8
>>   0  129    1          1          0     00300380    0.0  @CGI
>>   0  130    7          10         0     00300182    0.0  LOG
>>   0  131    1          2          0     00300184    0.0  IOXP
>>   0  142    20         42         0     00300380    0.0  KTMR
>>   0  151    1652       1901       0     00300380    0.0  Sdrv
>>   0  152    383        489        0     00300380    0.0  LApp
>>   0  156    0          1          0     00300380    0.0  DOS9
>>   0  0      0          14937556   0     00000000    1.0  IRQ16: [timer]
>>
>> Most of them are in state 00300380, that means:
>>   XNSTARTED
>>   XNMAPPED
>>   XNRELAXED
>>   XNFPU
>>   XNSHADOW
>>
>> For a deadlock I would expect all threads must be wait for a semaphore or 
>> something else (state flag XNPEND). However all tasks are freezed.
>
> Well no, XNRELAXED state means that it is suspended from xenomai
> scheduler point of view, and handled by Linux scheduler. So, if
> there is a deadlock, it happens in secondary mode.

The callstack in /proc/[PID]/tasks/[TID]/stack of all threads shows that they 
are at same address in __xnpod_schedule:

Call stack for task with TID 128:

~ # cat /proc/128/tasks/128/stack
[<c00a8a78>] __xnpod_schedule+0x294/0x764
[<c00a92a4>] xnpod_suspend_thread+0x2c0/0x354
[<c00b6b48>] xnshadow_relax+0x94/0x168
[<c00b7384>] losyscall_event+0x240/0x26c
[<c007c6fc>] ipipe_syscall_hook+0x44/0x54
[<c0078474>] __ipipe_notify_syscall+0x70/0x1d0
[<c0016820>] __ipipe_syscall_root+0x6c/0x194
[<c000f734>] vector_swi+0x74/0x8c
[<ffffffff>] 0xffffffff

With addr2line I have identified the if-statement as below on address c00a8a78 
(found in kernel/xenomai/nucleus/pod.c:2256):

  if (shadow && xnarch_root_domain_p())

Before this line there is the call xnpod_switch_to(sched, prev, next). So I 
assume the thread has not resumed from context switch.

Do you have any more idea?

Regards,
Christoph

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to