[Xenomai-core] SMP build failure (2.6.28)

[Xenomai-core] SMP build failure (2.6.28)

[Paul]

Patching a 2.6.28.2 with the relevant patch in trunk, using a config with SMP 
enabled resulted in:

  LD      kernel/xenomai/arch/built-in.o
  CC      kernel/xenomai/nucleus/heap.o
In file included from include/xenomai/nucleus/pod.h:34,
                 from kernel/xenomai/nucleus/heap.c:66:
include/xenomai/nucleus/sched.h: In function ‘xnsched_self_resched_p’:
include/xenomai/nucleus/sched.h:171: error: ‘nkpod’ undeclared (first use in 
this function)
include/xenomai/nucleus/sched.h:171: error: (Each undeclared identifier is 
reported only once
include/xenomai/nucleus/sched.h:171: error: for each function it appears in.)
make[3]: *** [kernel/xenomai/nucleus/heap.o] Error 1


Digging in to the nucleus/sched.h and nucleus/pod.h headers, there appears to 
be a circular dependency around nkpod_struct - This only hits home with 
CONFIG_SMP defined.


Regards, Paul.

Re: [Xenomai-core] SMP build failure (2.6.28)

[Gilles Chanteperdrix]

Paul wrote:
> Patching a 2.6.28.2 with the relevant patch in trunk, using a config with SMP 
> enabled resulted in:
> 
>   LD      kernel/xenomai/arch/built-in.o
>   CC      kernel/xenomai/nucleus/heap.o
> In file included from include/xenomai/nucleus/pod.h:34,
>                  from kernel/xenomai/nucleus/heap.c:66:
> include/xenomai/nucleus/sched.h: In function ‘xnsched_self_resched_p’:
> include/xenomai/nucleus/sched.h:171: error: ‘nkpod’ undeclared (first use in 
> this function)
> include/xenomai/nucleus/sched.h:171: error: (Each undeclared identifier is 
> reported only once
> include/xenomai/nucleus/sched.h:171: error: for each function it appears in.)
> make[3]: *** [kernel/xenomai/nucleus/heap.o] Error 1
> 
> 
> Digging in to the nucleus/sched.h and nucleus/pod.h headers, there appears to 
> be a circular dependency around nkpod_struct - This only hits home with 
> CONFIG_SMP defined.

There must be some other option triggering the bug, because I run trunk
with 2.6.28 on an SMP x86(_64).

-- 
					    Gilles.

Re: [Xenomai-core] SMP build failure (2.6.28)

[Paul]

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

On Thursday 12 February 2009, Gilles Chanteperdrix wrote:
> Paul wrote:
> > Patching a 2.6.28.2 with the relevant patch in trunk, using a config with
> > SMP enabled resulted in:
> >
> >   LD      kernel/xenomai/arch/built-in.o
> >   CC      kernel/xenomai/nucleus/heap.o
> > In file included from include/xenomai/nucleus/pod.h:34,
> >                  from kernel/xenomai/nucleus/heap.c:66:
> > include/xenomai/nucleus/sched.h: In function ‘xnsched_self_resched_p’:
> > include/xenomai/nucleus/sched.h:171: error: ‘nkpod’ undeclared (first use
> > in this function)
> > include/xenomai/nucleus/sched.h:171: error: (Each undeclared identifier
> > is reported only once
> > include/xenomai/nucleus/sched.h:171: error: for each function it appears
> > in.) make[3]: *** [kernel/xenomai/nucleus/heap.o] Error 1
> >
> >
> > Digging in to the nucleus/sched.h and nucleus/pod.h headers, there
> > appears to be a circular dependency around nkpod_struct - This only hits
> > home with CONFIG_SMP defined.
>
> There must be some other option triggering the bug, because I run trunk
> with 2.6.28 on an SMP x86(_64).

Attached, tarball of the two configs - One for SMP, the other, UP, both for 
32Bit.

Looking at the changelog, I see xnsched_self_resched_p was introduced in 
r4611 - Reverting the change allows compilation to progress...


Regards, Paul.




[-- Attachment #2: configs.bz2 --]
[-- Type: application/x-bzip2, Size: 29763 bytes --]

Re: [Xenomai-core] SMP build failure (2.6.28)

[Gilles Chanteperdrix]

Paul wrote:
> On Thursday 12 February 2009, Gilles Chanteperdrix wrote:
>> Paul wrote:
>>> Patching a 2.6.28.2 with the relevant patch in trunk, using a config with
>>> SMP enabled resulted in:
>>>
>>>   LD      kernel/xenomai/arch/built-in.o
>>>   CC      kernel/xenomai/nucleus/heap.o
>>> In file included from include/xenomai/nucleus/pod.h:34,
>>>                  from kernel/xenomai/nucleus/heap.c:66:
>>> include/xenomai/nucleus/sched.h: In function ‘xnsched_self_resched_p’:
>>> include/xenomai/nucleus/sched.h:171: error: ‘nkpod’ undeclared (first use
>>> in this function)
>>> include/xenomai/nucleus/sched.h:171: error: (Each undeclared identifier
>>> is reported only once
>>> include/xenomai/nucleus/sched.h:171: error: for each function it appears
>>> in.) make[3]: *** [kernel/xenomai/nucleus/heap.o] Error 1
>>>
>>>
>>> Digging in to the nucleus/sched.h and nucleus/pod.h headers, there
>>> appears to be a circular dependency around nkpod_struct - This only hits
>>> home with CONFIG_SMP defined.
>> There must be some other option triggering the bug, because I run trunk
>> with 2.6.28 on an SMP x86(_64).
> 
> Attached, tarball of the two configs - One for SMP, the other, UP, both for 
> 32Bit.
> 
> Looking at the changelog, I see xnsched_self_resched_p was introduced in 
> r4611 - Reverting the change allows compilation to progress...

The following patch replaces a division by a memory access, which should
be better on low-end and seems to fix the issue.

Index: include/nucleus/sched.h
===================================================================
--- include/nucleus/sched.h	(revision 4623)
+++ include/nucleus/sched.h	(working copy)
@@ -64,6 +64,7 @@ struct xnsched_rt {
 typedef struct xnsched {
 
 	xnflags_t status;		/*!< Scheduler specific status bitmask. */
+	int cpu;
 	struct xnthread *curr;		/*!< Current thread. */
 	xnarch_cpumask_t resched;	/*!< Mask of CPUs needing rescheduling. */
 
@@ -155,7 +156,7 @@ struct xnsched_class {
 #define XNSCHED_RUNPRIO   0x80000000
 
 #ifdef CONFIG_SMP
-#define xnsched_cpu(__sched__)	((__sched__) - &nkpod->sched[0])
+#define xnsched_cpu(__sched__)	((__sched__)->cpu)
 #else /* !CONFIG_SMP */
 #define xnsched_cpu(__sched__)	({ (void)__sched__; 0; })
 #endif /* CONFIG_SMP */
@@ -228,7 +229,7 @@ static inline void xnsched_reset_watchdo
 
 int xnsched_register_class(struct xnsched_class *sched_class);
 
-void xnsched_init(struct xnsched *sched);
+void xnsched_init(struct xnsched *sched, int cpu);
 
 void xnsched_destroy(struct xnsched *sched);
 
Index: ksrc/nucleus/pod.c
===================================================================
--- ksrc/nucleus/pod.c	(revision 4623)
+++ ksrc/nucleus/pod.c	(working copy)
@@ -407,7 +407,7 @@ int xnpod_init(void)
 
 	for (cpu = 0; cpu < nr_cpus; ++cpu) {
 		sched = &pod->sched[cpu];
-		xnsched_init(sched);
+		xnsched_init(sched, cpu);
 		appendq(&pod->threadq, &sched->rootcb.glink);
 	}
 
Index: ksrc/nucleus/sched.c
===================================================================
--- ksrc/nucleus/sched.c	(revision 4623)
+++ ksrc/nucleus/sched.c	(working copy)
@@ -82,15 +82,16 @@ static void xnsched_watchdog_handler(str
 
 #endif /* CONFIG_XENO_OPT_WATCHDOG */
 
-void xnsched_init(struct xnsched *sched)
+void xnsched_init(struct xnsched *sched, int cpu)
 {
 	char htimer_name[XNOBJECT_NAME_LEN];
 	char root_name[XNOBJECT_NAME_LEN];
 	union xnsched_policy_param param;
 	struct xnthread_init_attr attr;
-	int cpu = xnsched_cpu(sched);
 	struct xnsched_class *p;
 
+	sched->cpu = cpu;
+
 	for_each_xnsched_class(p) {
 		if (p->sched_init)
 			p->sched_init(sched);

-- 
					    Gilles.