[Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Niklaus Giger]

Hi

All my PPC based compilation fail with something like

ccache gcc -rdynamic -o .libs/rtcanconfig 
rtcanconfig.o  -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib
/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: 
undefined reference to `pthread_kill'
http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0
Is this only a PPC problem? It appears first with build 226, which referred to 
revisions 1433 and 1434. Details see 
http://ngiger.dyndns.org/buildbot/ppc/builds/226

Jan, could you please have a look at the error, as it seems to me that you 
reduced the lib dependencies a little bit too much?

Jan BTW, I also switched the RTNet svn to the new location. 

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Jan Kiszka]

Niklaus Giger wrote:
> Hi
> 
> All my PPC based compilation fail with something like
> 
> ccache gcc -rdynamic -o .libs/rtcanconfig 
> rtcanconfig.o  -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib
> /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: 
> undefined reference to `pthread_kill'
> http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0
> Is this only a PPC problem? It appears first with build 226, which referred to 
> revisions 1433 and 1434. Details see 
> http://ngiger.dyndns.org/buildbot/ppc/builds/226
> 
> Jan, could you please have a look at the error, as it seems to me that you 
> reduced the lib dependencies a little bit too much?

Well, neither rtcanconfig nor librtdm have explicit dependencies on
libpthread. Unfortunately, the generic skin init code now drags in
pthread_kill when the linker fails to remove xeno_handle_mlock_alert for
librtdm. That doesn't happen with my gcc-4.1, likely older compilers are
less smart.

Anyone any ideas how to solve it WITHOUT adding -lpthread to librtdm? I
would say either move that functions to a separate module or include it
via a separate header that all skins include except rtdm.

> 
> Jan BTW, I also switched the RTNet svn to the new location. 

Looking forward to the build results once we get xenomai compiling
again. A lot of stuff changed or got added recently.

> 
> Best regards
> 

Jan

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Philippe Gerum]

On Tue, 2006-08-15 at 10:15 +0200, Jan Kiszka wrote:
> Niklaus Giger wrote:
> > Hi
> > 
> > All my PPC based compilation fail with something like
> > 
> > ccache gcc -rdynamic -o .libs/rtcanconfig 
> > rtcanconfig.o  -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib
> > /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: 
> > undefined reference to `pthread_kill'
> > http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0
> > Is this only a PPC problem? It appears first with build 226, which referred to 
> > revisions 1433 and 1434. Details see 
> > http://ngiger.dyndns.org/buildbot/ppc/builds/226
> > 
> > Jan, could you please have a look at the error, as it seems to me that you 
> > reduced the lib dependencies a little bit too much?
> 
> Well, neither rtcanconfig nor librtdm have explicit dependencies on
> libpthread. Unfortunately, the generic skin init code now drags in
> pthread_kill when the linker fails to remove xeno_handle_mlock_alert for
> librtdm. That doesn't happen with my gcc-4.1, likely older compilers are
> less smart.
> 
> Anyone any ideas how to solve it WITHOUT adding -lpthread to librtdm?

Could you develop a bit more, i.e. what's the issue with adding this
dependency?

>  I
> would say either move that functions to a separate module

The reason to have this code in nucleus/bind.h is that we don't have any
dependency on common libs aside of the ones providing the skin syscalls,
and we try to avoid code duplication by not implementing this stuff into
each and every init.c files.

>  or include it
> via a separate header that all skins include except rtdm.
> 

I'm still reluctant to make RTDM an exception to the common rule,
especially to fix a compiler issue.

> > 
> > Jan BTW, I also switched the RTNet svn to the new location. 
> 
> Looking forward to the build results once we get xenomai compiling
> again. A lot of stuff changed or got added recently.
> 
> > 
> > Best regards
> > 
> 
> Jan
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 2804 bytes --]

Philippe Gerum wrote:
> On Tue, 2006-08-15 at 10:15 +0200, Jan Kiszka wrote:
>> Niklaus Giger wrote:
>>> Hi
>>>
>>> All my PPC based compilation fail with something like
>>>
>>> ccache gcc -rdynamic -o .libs/rtcanconfig 
>>> rtcanconfig.o  -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib
>>> /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: 
>>> undefined reference to `pthread_kill'
>>> http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0
>>> Is this only a PPC problem? It appears first with build 226, which referred to 
>>> revisions 1433 and 1434. Details see 
>>> http://ngiger.dyndns.org/buildbot/ppc/builds/226
>>>
>>> Jan, could you please have a look at the error, as it seems to me that you 
>>> reduced the lib dependencies a little bit too much?
>> Well, neither rtcanconfig nor librtdm have explicit dependencies on
>> libpthread. Unfortunately, the generic skin init code now drags in
>> pthread_kill when the linker fails to remove xeno_handle_mlock_alert for
>> librtdm. That doesn't happen with my gcc-4.1, likely older compilers are
>> less smart.
>>
>> Anyone any ideas how to solve it WITHOUT adding -lpthread to librtdm?
> 
> Could you develop a bit more, i.e. what's the issue with adding this
> dependency?

It's simply unneeded. This is only a single tiny tool, but we may see
more of them in the future, so I would like to clean this up now.

> 
>>  I
>> would say either move that functions to a separate module
> 
> The reason to have this code in nucleus/bind.h is that we don't have any
> dependency on common libs aside of the ones providing the skin syscalls,
> and we try to avoid code duplication by not implementing this stuff into
> each and every init.c files.
> 
>>  or include it
>> via a separate header that all skins include except rtdm.
>>
> 
> I'm still reluctant to make RTDM an exception to the common rule,
> especially to fix a compiler issue.

Actually, the issue is slightly broader, though with varying
significance. The current approach drags xeno_handle_mlock_alert and
xeno_sigxcpu_no_mlock multiple times into the skin lib. Even with
gcc-4.1 that increases libnative by a few data bytes, under 3.3 by ~300
byte of dead code (overall increase of /lib with 3.3: 32 Kbyte).

The attached patch solves both the linking issue and avoids multiple
static includes of code and variables that are only required once. I
think it's cleaner this way, following the idea of asm/bits/ (BTW,
should it become a asm-generic/bits header?).

Jan

[-- Attachment #1.2: separate_mlock_alert.patch --]
[-- Type: text/plain, Size: 4045 bytes --]

Index: include/nucleus/mlock_alert.h
===================================================================
--- include/nucleus/mlock_alert.h	(revision 0)
+++ include/nucleus/mlock_alert.h	(revision 0)
@@ -0,0 +1,37 @@
+#ifndef _XENO_NUCLEUS_MLOCK_ALERT_H
+#define _XENO_NUCLEUS_MLOCK_ALERT_H
+
+#ifndef __XENO_SIM__
+#include <stdio.h>
+#include <stdlib.h>
+#include <signal.h>
+#include <pthread.h>
+
+__attribute__ ((weak))
+int xeno_sigxcpu_no_mlock = 1;
+
+__attribute__ ((visibility ("internal")))
+void xeno_handle_mlock_alert(int sig)
+{
+	struct sigaction sa;
+
+	if (xeno_sigxcpu_no_mlock) {
+		fprintf(stderr, "Xenomai: process memory not locked "
+			"(missing mlockall?)\n");
+		fflush(stderr);
+		exit(4);
+	}
+
+	/* XNTRAPSW was set for the thread but no user-defined handler
+	   has been set to override our internal handler, so let's
+	   invoke the default signal action. */
+
+	sa.sa_handler = SIG_DFL;
+	sigemptyset(&sa.sa_mask);
+	sa.sa_flags = 0;
+	sigaction(SIGXCPU, &sa, NULL);
+	pthread_kill(pthread_self(), SIGXCPU);
+}
+#endif /* __XENO_SIM__ */
+
+#endif /* _XENO_NUCLEUS_MLOCK_ALERT_H */
Index: include/nucleus/bind.h
===================================================================
--- include/nucleus/bind.h	(revision 1440)
+++ include/nucleus/bind.h	(working copy)
@@ -6,33 +6,9 @@
 #include <string.h>
 #include <errno.h>
 #include <signal.h>
-#include <pthread.h>
 #include <asm/xenomai/syscall.h>
 
-__attribute__ ((weak))
-int xeno_sigxcpu_no_mlock = 1;
-
-static void xeno_handle_mlock_alert(int sig)
-{
-	struct sigaction sa;
-
-	if (xeno_sigxcpu_no_mlock) {
-		fprintf(stderr,
-			"Xenomai: process memory not locked (missing mlockall?)\n");
-		fflush(stderr);
-		exit(4);
-	}
-
-	/* XNTRAPSW was set for the thread but no user-defined handler
-	   has been set to override our internal handler, so let's
-	   invoke the default signal action. */
-
-	sa.sa_handler = SIG_DFL;
-	sigemptyset(&sa.sa_mask);
-	sa.sa_flags = 0;
-	sigaction(SIGXCPU, &sa, NULL);
-	pthread_kill(pthread_self(), SIGXCPU);
-}
+void xeno_handle_mlock_alert(int sig);
 
 static inline int
 xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
Index: src/skins/rtai/init.c
===================================================================
--- src/skins/rtai/init.c	(revision 1440)
+++ src/skins/rtai/init.c	(working copy)
@@ -20,6 +20,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <rtai/syscall.h>
+#include <nucleus/mlock_alert.h>
 
 int __rtai_muxid = -1;
 
Index: src/skins/posix/init.c
===================================================================
--- src/skins/posix/init.c	(revision 1440)
+++ src/skins/posix/init.c	(working copy)
@@ -26,6 +26,7 @@
 #include <posix/posix.h>
 #include <posix/syscall.h>
 #include <rtdm/syscall.h>
+#include <nucleus/mlock_alert.h>
 
 int __pse51_muxid = -1;
 int __rtdm_muxid = -1;
Index: src/skins/vxworks/init.c
===================================================================
--- src/skins/vxworks/init.c	(revision 1440)
+++ src/skins/vxworks/init.c	(working copy)
@@ -23,6 +23,7 @@
 #include <stdlib.h>
 #include <pthread.h>
 #include <vxworks/vxworks.h>
+#include <nucleus/mlock_alert.h>
 
 pthread_key_t __vxworks_tskey;
 
Index: src/skins/vrtx/init.c
===================================================================
--- src/skins/vrtx/init.c	(revision 1440)
+++ src/skins/vrtx/init.c	(working copy)
@@ -23,6 +23,7 @@
 #include <stdlib.h>
 #include <pthread.h>
 #include <vrtx/vrtx.h>
+#include <nucleus/mlock_alert.h>
 
 pthread_key_t __vrtx_tskey;
 
Index: src/skins/native/init.c
===================================================================
--- src/skins/native/init.c	(revision 1440)
+++ src/skins/native/init.c	(working copy)
@@ -24,6 +24,7 @@
 #include <pthread.h>
 #include <native/syscall.h>
 #include <native/task.h>
+#include <nucleus/mlock_alert.h>
 
 pthread_key_t __native_tskey;
 

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

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Philippe Gerum]

On Tue, 2006-08-15 at 14:20 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Tue, 2006-08-15 at 10:15 +0200, Jan Kiszka wrote:
> >> Niklaus Giger wrote:
> >>> Hi
> >>>
> >>> All my PPC based compilation fail with something like
> >>>
> >>> ccache gcc -rdynamic -o .libs/rtcanconfig 
> >>> rtcanconfig.o  -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib
> >>> /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: 
> >>> undefined reference to `pthread_kill'
> >>> http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0
> >>> Is this only a PPC problem? It appears first with build 226, which referred to 
> >>> revisions 1433 and 1434. Details see 
> >>> http://ngiger.dyndns.org/buildbot/ppc/builds/226
> >>>
> >>> Jan, could you please have a look at the error, as it seems to me that you 
> >>> reduced the lib dependencies a little bit too much?
> >> Well, neither rtcanconfig nor librtdm have explicit dependencies on
> >> libpthread. Unfortunately, the generic skin init code now drags in
> >> pthread_kill when the linker fails to remove xeno_handle_mlock_alert for
> >> librtdm. That doesn't happen with my gcc-4.1, likely older compilers are
> >> less smart.
> >>
> >> Anyone any ideas how to solve it WITHOUT adding -lpthread to librtdm?
> > 
> > Could you develop a bit more, i.e. what's the issue with adding this
> > dependency?
> 
> It's simply unneeded. This is only a single tiny tool, but we may see
> more of them in the future, so I would like to clean this up now.
> 

Sounds reasonable.

> > 
> >>  I
> >> would say either move that functions to a separate module
> > 
> > The reason to have this code in nucleus/bind.h is that we don't have any
> > dependency on common libs aside of the ones providing the skin syscalls,
> > and we try to avoid code duplication by not implementing this stuff into
> > each and every init.c files.
> > 
> >>  or include it
> >> via a separate header that all skins include except rtdm.
> >>
> > 
> > I'm still reluctant to make RTDM an exception to the common rule,
> > especially to fix a compiler issue.
> 
> Actually, the issue is slightly broader, though with varying
> significance. The current approach drags xeno_handle_mlock_alert and
> xeno_sigxcpu_no_mlock multiple times into the skin lib. Even with
> gcc-4.1 that increases libnative by a few data bytes, under 3.3 by ~300
> byte of dead code (overall increase of /lib with 3.3: 32 Kbyte).
> 
> The attached patch solves both the linking issue and avoids multiple
> static includes of code and variables that are only required once. I

Ok, this patch looks ok and does not rely on funky file-scoped macros,
which is good (this is what I would not want to see in the tree anymore,
hence the bits/ scheme).

> think it's cleaner this way, following the idea of asm/bits/ (BTW,
> should it become a asm-generic/bits header?).
> 

Probably, yes; and the same goes for nucleus/bind.h. In which case,
checking for __XENO_SIM__ would become useless. In any case, the various
init.c files are not parsed by the compiler when building the simulated
environment.

> Jan
> plain text document attachment (separate_mlock_alert.patch)
> Index: include/nucleus/mlock_alert.h
> ===================================================================
> --- include/nucleus/mlock_alert.h	(revision 0)
> +++ include/nucleus/mlock_alert.h	(revision 0)
> @@ -0,0 +1,37 @@
> +#ifndef _XENO_NUCLEUS_MLOCK_ALERT_H
> +#define _XENO_NUCLEUS_MLOCK_ALERT_H
> +
> +#ifndef __XENO_SIM__
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <pthread.h>
> +
> +__attribute__ ((weak))
> +int xeno_sigxcpu_no_mlock = 1;
> +
> +__attribute__ ((visibility ("internal")))
> +void xeno_handle_mlock_alert(int sig)
> +{
> +	struct sigaction sa;
> +
> +	if (xeno_sigxcpu_no_mlock) {
> +		fprintf(stderr, "Xenomai: process memory not locked "
> +			"(missing mlockall?)\n");
> +		fflush(stderr);
> +		exit(4);
> +	}
> +
> +	/* XNTRAPSW was set for the thread but no user-defined handler
> +	   has been set to override our internal handler, so let's
> +	   invoke the default signal action. */
> +
> +	sa.sa_handler = SIG_DFL;
> +	sigemptyset(&sa.sa_mask);
> +	sa.sa_flags = 0;
> +	sigaction(SIGXCPU, &sa, NULL);
> +	pthread_kill(pthread_self(), SIGXCPU);
> +}
> +#endif /* __XENO_SIM__ */
> +
> +#endif /* _XENO_NUCLEUS_MLOCK_ALERT_H */
> Index: include/nucleus/bind.h
> ===================================================================
> --- include/nucleus/bind.h	(revision 1440)
> +++ include/nucleus/bind.h	(working copy)
> @@ -6,33 +6,9 @@
>  #include <string.h>
>  #include <errno.h>
>  #include <signal.h>
> -#include <pthread.h>
>  #include <asm/xenomai/syscall.h>
>  
> -__attribute__ ((weak))
> -int xeno_sigxcpu_no_mlock = 1;
> -
> -static void xeno_handle_mlock_alert(int sig)
> -{
> -	struct sigaction sa;
> -
> -	if (xeno_sigxcpu_no_mlock) {
> -		fprintf(stderr,
> -			"Xenomai: process memory not locked (missing mlockall?)\n");
> -		fflush(stderr);
> -		exit(4);
> -	}
> -
> -	/* XNTRAPSW was set for the thread but no user-defined handler
> -	   has been set to override our internal handler, so let's
> -	   invoke the default signal action. */
> -
> -	sa.sa_handler = SIG_DFL;
> -	sigemptyset(&sa.sa_mask);
> -	sa.sa_flags = 0;
> -	sigaction(SIGXCPU, &sa, NULL);
> -	pthread_kill(pthread_self(), SIGXCPU);
> -}
> +void xeno_handle_mlock_alert(int sig);
>  
>  static inline int
>  xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
> Index: src/skins/rtai/init.c
> ===================================================================
> --- src/skins/rtai/init.c	(revision 1440)
> +++ src/skins/rtai/init.c	(working copy)
> @@ -20,6 +20,7 @@
>  #include <stdlib.h>
>  #include <string.h>
>  #include <rtai/syscall.h>
> +#include <nucleus/mlock_alert.h>
>  
>  int __rtai_muxid = -1;
>  
> Index: src/skins/posix/init.c
> ===================================================================
> --- src/skins/posix/init.c	(revision 1440)
> +++ src/skins/posix/init.c	(working copy)
> @@ -26,6 +26,7 @@
>  #include <posix/posix.h>
>  #include <posix/syscall.h>
>  #include <rtdm/syscall.h>
> +#include <nucleus/mlock_alert.h>
>  
>  int __pse51_muxid = -1;
>  int __rtdm_muxid = -1;
> Index: src/skins/vxworks/init.c
> ===================================================================
> --- src/skins/vxworks/init.c	(revision 1440)
> +++ src/skins/vxworks/init.c	(working copy)
> @@ -23,6 +23,7 @@
>  #include <stdlib.h>
>  #include <pthread.h>
>  #include <vxworks/vxworks.h>
> +#include <nucleus/mlock_alert.h>
>  
>  pthread_key_t __vxworks_tskey;
>  
> Index: src/skins/vrtx/init.c
> ===================================================================
> --- src/skins/vrtx/init.c	(revision 1440)
> +++ src/skins/vrtx/init.c	(working copy)
> @@ -23,6 +23,7 @@
>  #include <stdlib.h>
>  #include <pthread.h>
>  #include <vrtx/vrtx.h>
> +#include <nucleus/mlock_alert.h>
>  
>  pthread_key_t __vrtx_tskey;
>  
> Index: src/skins/native/init.c
> ===================================================================
> --- src/skins/native/init.c	(revision 1440)
> +++ src/skins/native/init.c	(working copy)
> @@ -24,6 +24,7 @@
>  #include <pthread.h>
>  #include <native/syscall.h>
>  #include <native/task.h>
> +#include <nucleus/mlock_alert.h>
>  
>  pthread_key_t __native_tskey;
>  
-- 
Philippe.

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Jan Kiszka]

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

Niklaus Giger wrote:
> Hi
> 
> All my PPC based compilation fail with something like
> ...

Things start to work again, but other issues pop up now.

o The installation step of xenomai on the tqm860 is broken. For that
  reason RTnet fails to configure. Please have a look, Niklaus.

o The simulator fails in both the posix and vxworks part:
  http://ngiger.dyndns.org/buildbot/sim/builds/258/step-check_sim/0
  Could anyone have a look?

o The run test on the hcu_vx seems to cause a hang after the nucleus
  being loaded:
  http://ngiger.dyndns.org/buildbot/hcu_vx/builds/128/step-xeno-test/0

hcu3 is fine, a rebuild of "ppc" is currently pending.

A few remarks and wishes:

o Some list of the characteristics of those systems would be nice, just
  to gain overview what the differences are.

o Maybe it's useful to strip the kernel configs of some systems
  (non-related drivers etc.) to reduce the turn-around time.

o Some kind of allyesconfig for Xenomai would be nice. 2.4 doesn't seem
  to have this, but maybe one can derive that from a 2.6 .config, grab
  all XENO-related switches, and append them to the 2.4 .config. This
  way new stuff like the CAN stack now would get included faster.

On final remark I can only repeat over and over again:

Your buildbot is really great stuff! It significantly reduces the
round-trip time for detecting and fixing (often trivial) build issues as
long as there are not yet millions of Xenomai users updating their SVN
checkout every day ;)

Thanks,
Jan


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

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Niklaus Giger]

Am Dienstag, 15. August 2006 20:14 schrieb Jan Kiszka:
> Niklaus Giger wrote:
> > Hi
> >
> > All my PPC based compilation fail with something like
> > ...
>
> Things start to work again, but other issues pop up now.
>
> o The installation step of xenomai on the tqm860 is broken. For that
>   reason RTnet fails to configure. Please have a look, Niklaus.
I had noticed this just before the compile issues popped up. I will have a 
look, but the whole buildbot system is quite complex and confuses sometimes 
even its creator.
> o The simulator fails in both the posix and vxworks part:
>   http://ngiger.dyndns.org/buildbot/sim/builds/258/step-check_sim/0
I reported the error "vxworks->t010823-2:t010823-2.c:163: Expected sequence: 
SEQ("Test2",2009); got SEQ("Test2",2003)" some time ago. Looks like a minor 
issue to me, as the simulator has its own internal timing. But I always 
prefer that Gilles fixes these kind of errors.

>   Could anyone have a look?
The other errors in the POSIX skin are new and need to be looked at.

>
> o The run test on the hcu_vx seems to cause a hang after the nucleus
>   being loaded:
>   http://ngiger.dyndns.org/buildbot/hcu_vx/builds/128/step-xeno-test/0
This is a long standing problem, where Philippe needs to get hand on a PPC40x 
system to find the error. I tried to give it a look
> hcu3 is fine, a rebuild of "ppc" is currently pending.
hcu3 is the most important target (at least for me), as it is the only target 
which runs xeno-test.
>
> A few remarks and wishes:
>
> o Some list of the characteristics of those systems would be nice, just
>   to gain overview what the differences are.

I will try to fix my documentation. But from the beginning I wanted to 
introduce as much variance as possible in the different buildings, therefore 
I intentionally used different gcc versions, cross-compiling vs native, only 
xenomai vs xenomai+RTnet, POSIX vs VXWORKS, everything built-in vs everything 
as a module. Looking at all the different log files (I know that this is time 
consuming) usually gives me quite a few of the answers.

>
> o Maybe it's useful to strip the kernel configs of some systems
>   (non-related drivers etc.) to reduce the turn-around time.
I was thinking about it, but it is only the ppc build which takes a long time 
to build and I am running usually a specific build of this kernel to assure 
me that Xenomai is working all right in a real environment.

Roundtrip time could also be improved if more buildbot slave were added. 
Though if anybody has a spare machine running all the time which could 
support the load of Xenomai builds, I would be glad to help integrate another 
slaves into my buildbot system. It would be also possible to add specific 
slave for anybody who wants to be assured that the Xenomai trunk continues to 
work for his specific board and build environment.

>
> o Some kind of allyesconfig for Xenomai would be nice. 2.4 doesn't seem
>   to have this, but maybe one can derive that from a 2.6 .config, grab
>   all XENO-related switches, and append them to the 2.4 .config. This
>   way new stuff like the CAN stack now would get included faster.
A allyesconfig is not possible as e.g. VXWORKS and the POSIX-skin have 
mutually exclusive requirements for the timing system (periodic vs 
aperiodic).

If you want some specific CONFIG set please drop me a note.

>
> On final remark I can only repeat over and over again:
>
> Your buildbot is really great stuff! It significantly reduces the
> round-trip time for detecting and fixing (often trivial) build issues as
> long as there are not yet millions of Xenomai users updating their SVN
> checkout every day ;)
Thanks for the compliment. As long as everybody on the mailing list responds 
so well to my complaints that something is broken, I will remain motivated to 
invest my time.

Best regards
-- 
Niklaus Giger

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Jan Kiszka]

Niklaus Giger wrote:
> Am Dienstag, 15. August 2006 20:14 schrieb Jan Kiszka:
>> Niklaus Giger wrote:
>>> Hi
>>>
>>> All my PPC based compilation fail with something like
>>> ...
>> Things start to work again, but other issues pop up now.
>>
>> o The installation step of xenomai on the tqm860 is broken. For that
>>   reason RTnet fails to configure. Please have a look, Niklaus.
> I had noticed this just before the compile issues popped up. I will have a 
> look, but the whole buildbot system is quite complex and confuses sometimes 
> even its creator.

:)

>> o The simulator fails in both the posix and vxworks part:
>>   http://ngiger.dyndns.org/buildbot/sim/builds/258/step-check_sim/0
> I reported the error "vxworks->t010823-2:t010823-2.c:163: Expected sequence: 
> SEQ("Test2",2009); got SEQ("Test2",2003)" some time ago. Looks like a minor 
> issue to me, as the simulator has its own internal timing. But I always 
> prefer that Gilles fixes these kind of errors.
> 
>>   Could anyone have a look?
> The other errors in the POSIX skin are new and need to be looked at.

That looks to me (after finding out how to build that testsuite: make
check!) like it is related to latest changes on pthread_cond_xxx. Gilles
is on CC now.

> 
>> o The run test on the hcu_vx seems to cause a hang after the nucleus
>>   being loaded:
>>   http://ngiger.dyndns.org/buildbot/hcu_vx/builds/128/step-xeno-test/0
> This is a long standing problem, where Philippe needs to get hand on a PPC40x 
> system to find the error. I tried to give it a look

If you happen to have time, I would suggest narrowing the cause down by
switching synchronous printk on (ipipe_set_printk_sync(&rthal_root);
ipipe_set_printk_sync(rthal_root_domain);) and then spreading some
printk to the init routines of the nucleus, trying the find the
problematic line(s). This printk will even works under hard IRQ lock, so
also endless loops in the timer handler can be detected that way. It's
just a bit time-consuming for the operator...

>> hcu3 is fine, a rebuild of "ppc" is currently pending.
> hcu3 is the most important target (at least for me), as it is the only target 
> which runs xeno-test.
>> A few remarks and wishes:
>>
>> o Some list of the characteristics of those systems would be nice, just
>>   to gain overview what the differences are.
> 
> I will try to fix my documentation. But from the beginning I wanted to 
> introduce as much variance as possible in the different buildings, therefore 
> I intentionally used different gcc versions, cross-compiling vs native, only 
> xenomai vs xenomai+RTnet, POSIX vs VXWORKS, everything built-in vs everything 
> as a module. Looking at all the different log files (I know that this is time 
> consuming) usually gives me quite a few of the answers.

Is there already some doc somewhere? Maybe I was just blind.

> 
>> o Maybe it's useful to strip the kernel configs of some systems
>>   (non-related drivers etc.) to reduce the turn-around time.
> I was thinking about it, but it is only the ppc build which takes a long time 
> to build and I am running usually a specific build of this kernel to assure 
> me that Xenomai is working all right in a real environment.
> 
> Roundtrip time could also be improved if more buildbot slave were added. 
> Though if anybody has a spare machine running all the time which could 
> support the load of Xenomai builds, I would be glad to help integrate another 
> slaves into my buildbot system. It would be also possible to add specific 
> slave for anybody who wants to be assured that the Xenomai trunk continues to 
> work for his specific board and build environment.

Well, I would offer to spend a few cycles of our development server, but
our build environment and target boards are already the most common
ones: latest compiler on x86 for x86. Boring, I know...

> 
>> o Some kind of allyesconfig for Xenomai would be nice. 2.4 doesn't seem
>>   to have this, but maybe one can derive that from a 2.6 .config, grab
>>   all XENO-related switches, and append them to the 2.4 .config. This
>>   way new stuff like the CAN stack now would get included faster.
> A allyesconfig is not possible as e.g. VXWORKS and the POSIX-skin have 
> mutually exclusive requirements for the timing system (periodic vs 
> aperiodic).
> 
> If you want some specific CONFIG set please drop me a note.

Then please check for the CAN drivers (same as with RTnet: some only
build for PPC) and the latest switches of the POSIX skin.

> 
>> On final remark I can only repeat over and over again:
>>
>> Your buildbot is really great stuff! It significantly reduces the
>> round-trip time for detecting and fixing (often trivial) build issues as
>> long as there are not yet millions of Xenomai users updating their SVN
>> checkout every day ;)
> Thanks for the compliment. As long as everybody on the mailing list responds 
> so well to my complaints that something is broken, I will remain motivated to 
> invest my time.
> 

Ok, and if we do not respond, just yell loader! ;)

Jan

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Philippe Gerum]

On Tue, 2006-08-15 at 20:56 +0200, Niklaus Giger wrote:
> > o The run test on the hcu_vx seems to cause a hang after the nucleus
> >   being loaded:
> >   http://ngiger.dyndns.org/buildbot/hcu_vx/builds/128/step-xeno-test/0
> This is a long standing problem, where Philippe needs to get hand on a PPC40x 
> system to find the error. I tried to give it a look
> > hcu3 is fine, a rebuild of "ppc" is currently pending.
> hcu3 is the most important target (at least for me), as it is the only target 
> which runs xeno-test.

This one is spotted in the timer activation sequence during startup, but
I need to put my hands back on a 40x board (likely by September) to
solve it. This is high on the must-fix list for me too.

-- 
Philippe.

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Gilles Chanteperdrix]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 3122 bytes --]

Niklaus Giger wrote:
 > Am Dienstag, 15. August 2006 20:14 schrieb Jan Kiszka:
 > > Niklaus Giger wrote:
 > > > Hi
 > > >
 > > > All my PPC based compilation fail with something like
 > > > ...
 > >
 > > Things start to work again, but other issues pop up now.
 > >
 > > o The installation step of xenomai on the tqm860 is broken. For that
 > >   reason RTnet fails to configure. Please have a look, Niklaus.
 > I had noticed this just before the compile issues popped up. I will have a 
 > look, but the whole buildbot system is quite complex and confuses sometimes 
 > even its creator.
 > > o The simulator fails in both the posix and vxworks part:
 > >   http://ngiger.dyndns.org/buildbot/sim/builds/258/step-check_sim/0
 > I reported the error "vxworks->t010823-2:t010823-2.c:163: Expected sequence: 
 > SEQ("Test2",2009); got SEQ("Test2",2003)" some time ago. Looks like a minor 
 > issue to me, as the simulator has its own internal timing. But I always 
 > prefer that Gilles fixes these kind of errors.

 I am sorry I completely forgot about this issue.

 > 
 > >   Could anyone have a look?
 > The other errors in the POSIX skin are new and need to be looked at.

Ok. I am on it.


 > > Your buildbot is really great stuff! It significantly reduces the
 > > round-trip time for detecting and fixing (often trivial) build issues as
 > > long as there are not yet millions of Xenomai users updating their SVN
 > > checkout every day ;)
 > Thanks for the compliment. As long as everybody on the mailing list responds 
 > so well to my complaints that something is broken, I will remain motivated to 
 > invest my time.

Will try to improve this... I also have a small remark: I think
htmlified logs would be easier to read if it was possible to jump from
error to error. The following bash snippet allow to create such a
browsable log file from the plain text log file. Attached an example of
a log file htmlified with this script.


htmlify_logs() {
    local out=$1; shift
    local in=$1; shift
    local title=${1+"$@"}

    : > $out

    i=0
    cat >> $out <<EOF
<html>
<head>
<title>$title</title>
</head>
<body>
<a name="$i">
<table width="100%"><tr>
<td width="90%" align="right"><font color="red">warnings/errors:</td>
<td>previous</td>
<td><a href="#`expr $i + 1`">next</a></td>
</tr></table>
</font></a><br>
EOF
    i=1

    while read line; do
        if expr "$line" : '[^ ]\+:[0-9]\+' > /dev/null 2>&1 ||
            expr "$line" : '\*\*\* Warning' > /dev/null 2>&1; then
    cat <<EOF
<a name="$i">
<table width="100%"><tr>
<td width="90%"><font color="red">$line</td>
<td><a href="#`expr $i - 1`">previous</a></td>
<td><a href="#`expr $i + 1`">next</a></td>
</tr></table>
</font></a><br>
EOF
            i=`expr $i + 1`
        else
            echo "$line"'<br>'
        fi
    done < $in >> $out

    cat >> $out <<EOF
<a name="$i">
<table width="100%"><tr>
<td width="90%" align="right"><font color="red">warnings/errors:</td>
<td><a href="#`expr $i - 1`">previous</a></td>
<td>next</td>
</tr></table>
</font></a><br>
</body>
</html>
EOF

    expr $i - 1
}

-- 


					    Gilles Chanteperdrix.

[-- Attachment #2: log.html --]
[-- Type: text/html, Size: 351887 bytes --]

Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill

[Niklaus Giger]

Am Mittwoch, 16. August 2006 15:23 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
>  > Am Dienstag, 15. August 2006 20:14 schrieb Jan Kiszka:
>  > > Niklaus Giger wrote:
>  > > > Hi
> Will try to improve this... I also have a small remark: I think
> htmlified logs would be easier to read if it was possible to jump from
> error to error. The following bash snippet allow to create such a
> browsable log file from the plain text log file. Attached an example of
Yes, I remember that you suggested this approach a while ago. Unfortunatly 
buildbot up to the current version 0.7.3 has no facility to present a build 
log in any other way as a text file (HTML escaped).
In the buildbot trunk there are now possiblities to add a LogObserver. I will 
give it a try as soon as I have some spare hours.

Nice to find the simulator testsuite working fine again!

Best regards

-- 
Niklaus Giger