Re: Linux system got freezing when "Xenomai App" started (or terminated).

[Jan Kiszka <jan.kiszka@web.de>]

On 31.07.24 11:35, 임준수(Junesoo Im) 수석 두산로보틱스 wrote:
> Dear Jan,
>
>
> I am validating our Xenomai Application with following setup:
>
>    - Xenomai version: https://source.denx.de/Xenomai/xenomai/-/tree/v3.1.4
>    - Ipipe: https://source.denx.de/Xenomai/ipipe-x86/-/tree/ipipe-core-5.4.255-x86-15
>
>
>
> During Reliability Test in which we do the loop:
>     {
>         1. Boot up machine, start Xenomai application
>         2. Wait for 1 min
>         3. Reboot Machine
>     }
>
> Sometime we face the double-unlock issue right after starting Xenomai Application as below:
>     1. [   14.046242] [Xenomai] lock 00000000733490c8 already unlocked on CPU #1
>         [   14.046242]           last owner = kernel/xenomai/posix/process.c:1243 (handle_schedule_event(), CPU #-1)
>     2. [   13.787715] [Xenomai] lock 0000000054aa4b33 already unlocked on CPU #3
>         [   13.787715]           last owner = kernel/xenomai/posix/thread.c:91 (thread_hash(), CPU #0)
> In consequence, System hung up (with Soft lock/Hard lock printed) and cannot recover.
>
>
>
> I have done some searching and found this commit:
> https://lore.kernel.org/all/9de20ac1-f92f-693e-f205-c965a2c6b434@xenomai.org/
>
> As my understanding, this issue is caused by "xnlock_get()" which does not dissable the interrupt.
> So I have some questions:
>
>     1. Do you think our issue is related to "xnlock_get()"?
>         As I checked the kernel code, there are some places still using that API, while mostly "xnlock_get_irqsave()" is used.

We may have a corner case around the reboot code - or can you also
reproduce without rebooting?

Furthermore, please test with recent versions as well. I-pipe kernels
are in maintenance mode, receiving less attention and minimal updates
these days now.

>     2. Is "nklock" could also be accessed by POSIX kernel?
>     3. Is migrating back and forth between Primary and Secondary mode safe? As we previously experienced live-lock when calling Linux VDSO gettimeofday(),

This is architectural with legacy I-pipe. Another reason to move to >
5.4, thus dovetail.

Jan