Jan Kiszka wrote:
> As the xnsched structures get initialized later, during xnpod_init,
> xnsched_cpu always returned 0 in the gatekeeper_thread prologue. That
> caused binding of all gatekeepers to CPU 0.
>

Hey, nice. This is why v2.4.x used pointer arithmetics to determine the cpu # in
the first place.

> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
> ---
> 
>  ksrc/nucleus/shadow.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
> index 1dedd85..2243c0e 100644
> --- a/ksrc/nucleus/shadow.c
> +++ b/ksrc/nucleus/shadow.c
> @@ -823,11 +823,14 @@ static int gatekeeper_thread(void *data)
>       struct task_struct *this_task = current;
>       DECLARE_WAITQUEUE(wait, this_task);
>       struct xnsched *sched = data;
> -     int cpu = xnsched_cpu(sched);
>       struct xnthread *target;
>       cpumask_t cpumask;
> +     int cpu;
>       spl_t s;
>  
> +     /* sched not fully initialized, xnsched_cpu does not work yet */
> +     cpu = sched - nkpod_struct.sched;
> +
>       this_task->flags |= PF_NOFREEZE;
>       sigfillset(&this_task->blocked);
>       cpumask = cpumask_of_cpu(cpu);
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to