Re: [Xenomai-core] [bug] lock-up by failing rt_task_spawn/create

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jan Kiszka wrote:
>  > >  > BTW, this reminds me the ask for a merging plan of the kgdb support for
>  > >  > ipipe - this bug was tracked down via kgdb...
>  > > 
>  > > There are some issues with the kgdb patch:
>  > > - it does not work if the nucleus is compiled as a module, because it
>  > >   uses xnpod_current_thread()
>  > 
>  > I know, but I do not have a clean solution for this yet. A workaround
>  > would be to force the nucleus into the kernel via kconfig if the kgdb is
>  > enabled. Any other ideas how to detect kernel-only threads (i.e. invalid
>  > "current")?
> 
> If we suppose that the kgdb patch is made adeos aware, could we ask a
> domain-specific callback to be called when not running the root domain ?
> This callback would be set by Xenomai in an #ifdef CONFIG_KGDB section.

Sounds good, will try this.

> 
>  > 
>  > > - it does not work on SMP because the kgdb patch uses
>  > >   smp_processor_id(), which does not work on SMP over Xenomai domain.
>  > > 
>  > 
>  > Ok, but probably fixable. If simple search&replace in the kgdb patch is
>  > not enough, a similar workaround could be applied for now: disallow kgdb
>  > usage over SMP.
> 
> Since we are going to have this problem over and over again for each
> patch that we want to adapt to xenomai (ltt comes to my mind), maybe we
> could make smp_processor_id() in adeos patch safe to be called over non
> root domain by using ipipe_processor_id() when called over non-root
> domains.
> 
> I think there is currently no code that take advantage of the fact that
> the fast smp_processor_id() may safely be called over shadow threads, so
> the performance penalty of using ipipe_processor_id() will be minimal.
> 

What about the potential penalty for normal Linux callers of
smp_processor_id()? Would this degrade the overall performance
noticeably even if there is now kgdb or ltt? Or should we make this
"ipipe-safe" smp_processor_id() optional for such users?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]