[Xenomai-core] Buildbot is back (and reporting errors)

[Xenomai-core] Buildbot is back (and reporting errors)

[Niklaus Giger]

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

Hi

During the last two weeks I spent several evenings to bring the buildbot back 
into a good shape.

Please take a look at http://ngiger.dyndns.org/buildbot/ to see the some of 
the results.

I upgraded to the 0.7.6 buildbot revision which has a much improved web display.

It is therefore possible to limit one's view to specific branches (2.3.x/2.4.x/
2.5.x at the moment or just a specifiy builder (e.g. i386_f). I hope that this
makes looking for specific errors easier for everybody.

Most builder use a new approach. As before the buildbot checks out the desired
trunk/branch/tag, downloads the config and (if necessary) a board specific patch.
Then the attached make_xenomai.rb Ruby creates a script to checkout the desired
git branch, running the prepare-kernel.sh, configure, make etc. A short for is
available as in
http://ngiger.dyndns.org/buildbot/builders/yosemite_f/builds/0/steps/genscript/logs/cmd2run
The full script (which each line surrounded by a if ! cmd ; then exit 2; fi) is
then run. This approach should ease a developpers work to reproduce the environment
where the buildbot reported an error.

In the next few days (beside Christmas with my familiy, some skiing and friends)
I will improve it to handle "old" version like 2.3.x correctly. Also I will I
builds of the most recent tags in the 2.3. and 2.4 line. Or does someone see the
need for lines like 2.2/2.1 or 2.0?

Also planned is to add one ore more boards to running xeno-test, the Yosemite 
(PPC440EP based) and HCU3 (PPC405GPr based).

If somebody would like to add more boards please drop me an email (may be with
an attached config and a script to show how the build was done).

Now about the failures I noticed:

a) The simulator fails in two tests with the vxworks skins. In
http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/1/steps/check_sim/logs/stdio
you will find at the end the lines
> Some problems were reported in:
> vxworks->t010726-1::
> vxworks->t010823-2::
Going back one finds:
> starting VxWorks services.
> Xenoscope: lt-t010823-2: fatal in MvmIrq (time=30000718.974563):
> test interrupted by watchdog.
and
> starting VxWorks services.
> Xenoscope: lt-t010726-1: fatal in MvmIrq (time=30000718.974820):
> test interrupted by watchdog.

b) The i386 builds fails in
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c: In
> function 'metapage_read_end_io':
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c:295:
> warning: 'return' with a value, in function returning void
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c: In
> function 'metapage_write_end_io':
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c:352:
> warning: 'return' with a value, in function returning void CC [M] 
> fs/jfs/jfs_logmgr.o
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
> function 'lbmStartIO':
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2165:
> error: too many arguments to function 'lbmIODone'
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
> function 'lbmIODone':
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2238:
> warning: 'return' with a value, in function returning void
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2263:
> warning: 'return' with a value, in function returning void
> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2343:
> warning: 'return' with a value, in function returning void make[3]: ***
> [fs/jfs/jfs_logmgr.o] Error 1

c) The buildbot reported the following error for the PPC build in
http://ngiger.dyndns.org/buildbot/builders/ppc_f/builds/1/steps/build/logs/stdio
> /var/buildbot/slave/ppc_f/linux-2.6-xenomai/drivers/net/via-rhine.c:44:1:
> error: unterminated #ifndef make[3]: *** [drivers/net/via-rhine.o] Error 1
> make[2]: *** [drivers/net] Error 2
> make[1]: *** [drivers] Error 2

d) For my PPC405 board I got in
http://ngiger.dyndns.org/buildbot/builders/hcu3_f/builds/2/steps/build/logs/stdio
the error
>   CC      arch/ppc/kernel/smp.o
> /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c: In
> function 'start_secondary':
> /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
> error: implicit declaration of function 'get_paca'
> /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
> error: invalid type argument of '->'
> /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
> warning: cast from pointer to integer of different size make[2]: ***
> [arch/ppc/kernel/smp.o] Error 1
> make[1]: *** [arch/ppc/kernel] Error 2

e) For the TQM (here I am not sure whether I use a good combination of
the Linux tarball, xenomai and rtnet. So please drop me a note to correct
my error. The steps can be found in 
http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/1
but are distributed. I used the xenomai trunk,
ftp://ftp.denx.de/pub/linux/linuxppc_2_4_devel-2006-04-06-1735.tar.bz2
-adeos=ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-*.patch 
http://rtnet.svn.sourceforge.net/svnroot/rtnet/trunk/rtnet
To compile the linux kernel I called
make ARCH=ppc uImage modules
with the following environment flags:
  CFLAGS=-g
  CROSS_COMPILE=ppc_8xx-
In
http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/1/steps/mk_kernel/logs/stdio
you find the following errors:
> In file included from
> /home/buildbot/slave/tqm_f/linux/include/linux/unistd.h:9, from
> init/do_mounts.c:5:
> /home/buildbot/slave/tqm_f/linux/include/asm/unistd.h:385: warning:
> conflicting types for built-in function '_exit' init/do_mounts.c:54: error:
> static declaration of 'root_device_name' follows non-static declaration
> /home/buildbot/slave/tqm_f/linux/include/linux/fs.h:1568: error: previous
> declaration of 'root_device_name' was here init/do_mounts.c: In function
> 'identify_ramdisk_image':
> init/do_mounts.c:507: warning: pointer targets in passing argument 2 of
> 'read' differ in signedness init/do_mounts.c:542: warning: pointer targets
> in passing argument 2 of 'read' differ in signedness init/do_mounts.c: In
> function 'fill_inbuf':
> init/do_mounts.c:1006: warning: pointer targets in passing argument 2 of
> 'read' differ in signedness init/do_mounts.c: In function 'flush_window':
> init/do_mounts.c:1024: warning: pointer targets in passing argument 2 of
> 'write' differ in signedness make: *** [init/do_mounts.o] Error 1

Best regards
-- 
Niklaus Giger
Wieshoschet 6
CH-8753 Mollis
Tel. ++41 55 612 20 54 (privat)
Tel. ++41 55 618 64 68 (Geschäft)

[-- Attachment #2: make_xenomai.rb --]
[-- Type: application/x-ruby, Size: 11284 bytes --]

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > a) The simulator fails in two tests with the vxworks skins. In
 > http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/1/steps/check_sim/logs/stdio
 > you will find at the end the lines
 > > Some problems were reported in:
 > > vxworks->t010726-1::
 > > vxworks->t010823-2::
 > Going back one finds:
 > > starting VxWorks services.
 > > Xenoscope: lt-t010823-2: fatal in MvmIrq (time=30000718.974563):
 > > test interrupted by watchdog.
 > and
 > > starting VxWorks services.
 > > Xenoscope: lt-t010726-1: fatal in MvmIrq (time=30000718.974820):
 > > test interrupted by watchdog.

Ok, we look at these.

 > 
 > b) The i386 builds fails in
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c: In
 > > function 'metapage_read_end_io':
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c:295:
 > > warning: 'return' with a value, in function returning void
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c: In
 > > function 'metapage_write_end_io':
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_metapage.c:352:
 > > warning: 'return' with a value, in function returning void CC [M] 
 > > fs/jfs/jfs_logmgr.o
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
 > > function 'lbmStartIO':
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2165:
 > > error: too many arguments to function 'lbmIODone'
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
 > > function 'lbmIODone':
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2238:
 > > warning: 'return' with a value, in function returning void
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2263:
 > > warning: 'return' with a value, in function returning void
 > > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2343:
 > > warning: 'return' with a value, in function returning void make[3]: ***
 > > [fs/jfs/jfs_logmgr.o] Error 1
 > 
 > c) The buildbot reported the following error for the PPC build in
 > http://ngiger.dyndns.org/buildbot/builders/ppc_f/builds/1/steps/build/logs/stdio
 > > /var/buildbot/slave/ppc_f/linux-2.6-xenomai/drivers/net/via-rhine.c:44:1:
 > > error: unterminated #ifndef make[3]: *** [drivers/net/via-rhine.o] Error 1
 > > make[2]: *** [drivers/net] Error 2
 > > make[1]: *** [drivers] Error 2
 > 
 > d) For my PPC405 board I got in
 > http://ngiger.dyndns.org/buildbot/builders/hcu3_f/builds/2/steps/build/logs/stdio
 > the error
 > >   CC      arch/ppc/kernel/smp.o
 > > /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c: In
 > > function 'start_secondary':
 > > /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
 > > error: implicit declaration of function 'get_paca'
 > > /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
 > > error: invalid type argument of '->'
 > > /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
 > > warning: cast from pointer to integer of different size make[2]: ***
 > > [arch/ppc/kernel/smp.o] Error 1
 > > make[1]: *** [arch/ppc/kernel] Error 2
 > 
 > e) For the TQM (here I am not sure whether I use a good combination of
 > the Linux tarball, xenomai and rtnet. So please drop me a note to correct
 > my error. The steps can be found in 
 > http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/1
 > but are distributed. I used the xenomai trunk,
 > ftp://ftp.denx.de/pub/linux/linuxppc_2_4_devel-2006-04-06-1735.tar.bz2
 > -adeos=ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-*.patch 
 > http://rtnet.svn.sourceforge.net/svnroot/rtnet/trunk/rtnet
 > To compile the linux kernel I called
 > make ARCH=ppc uImage modules
 > with the following environment flags:
 >   CFLAGS=-g
 >   CROSS_COMPILE=ppc_8xx-
 > In
 > http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/1/steps/mk_kernel/logs/stdio
 > you find the following errors:
 > > In file included from
 > > /home/buildbot/slave/tqm_f/linux/include/linux/unistd.h:9, from
 > > init/do_mounts.c:5:
 > > /home/buildbot/slave/tqm_f/linux/include/asm/unistd.h:385: warning:
 > > conflicting types for built-in function '_exit' init/do_mounts.c:54: error:
 > > static declaration of 'root_device_name' follows non-static declaration
 > > /home/buildbot/slave/tqm_f/linux/include/linux/fs.h:1568: error: previous
 > > declaration of 'root_device_name' was here init/do_mounts.c: In function
 > > 'identify_ramdisk_image':
 > > init/do_mounts.c:507: warning: pointer targets in passing argument 2 of
 > > 'read' differ in signedness init/do_mounts.c:542: warning: pointer targets
 > > in passing argument 2 of 'read' differ in signedness init/do_mounts.c: In
 > > function 'fill_inbuf':
 > > init/do_mounts.c:1006: warning: pointer targets in passing argument 2 of
 > > 'read' differ in signedness init/do_mounts.c: In function 'flush_window':
 > > init/do_mounts.c:1024: warning: pointer targets in passing argument 2 of
 > > 'write' differ in signedness make: *** [init/do_mounts.o] Error 1


Are you sure these errors are related to Xenomai, do not you get the
same errors if you build the kernel without Xenomai enabled ? Also,
you should tell us which versions of Linux you used, and post a link to
the kernel configuration.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Philippe Gerum]

Niklaus Giger wrote:
> In
> http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/1/steps/mk_kernel/logs/stdio
> you find the following errors:
>> In file included from
>> /home/buildbot/slave/tqm_f/linux/include/linux/unistd.h:9, from
>> init/do_mounts.c:5:
>> /home/buildbot/slave/tqm_f/linux/include/asm/unistd.h:385: warning:
>> conflicting types for built-in function '_exit' init/do_mounts.c:54: error:
>> static declaration of 'root_device_name' follows non-static declaration
>> /home/buildbot/slave/tqm_f/linux/include/linux/fs.h:1568: error: previous
>> declaration of 'root_device_name' was here init/do_mounts.c: In function
>> 'identify_ramdisk_image':
>> init/do_mounts.c:507: warning: pointer targets in passing argument 2 of
>> 'read' differ in signedness init/do_mounts.c:542: warning: pointer targets
>> in passing argument 2 of 'read' differ in signedness init/do_mounts.c: In
>> function 'fill_inbuf':
>> init/do_mounts.c:1006: warning: pointer targets in passing argument 2 of
>> 'read' differ in signedness init/do_mounts.c: In function 'flush_window':
>> init/do_mounts.c:1024: warning: pointer targets in passing argument 2 of
>> 'write' differ in signedness make: *** [init/do_mounts.o] Error 1

You may want to switch back to ELDK-3.1.1 for compiling old 2.4/ppc
kernels. GCC 4.0 and beyond as shipped with recent ELDK releases are
less permissive regarding these issues.

-- 
Philippe.

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > a) The simulator fails in two tests with the vxworks skins. In
 > http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/1/steps/check_sim/logs/stdio
 > you will find at the end the lines
 > > Some problems were reported in:
 > > vxworks->t010726-1::
 > > vxworks->t010823-2::
 > Going back one finds:
 > > starting VxWorks services.
 > > Xenoscope: lt-t010823-2: fatal in MvmIrq (time=30000718.974563):
 > > test interrupted by watchdog.
 > and
 > > starting VxWorks services.
 > > Xenoscope: lt-t010726-1: fatal in MvmIrq (time=30000718.974820):
 > > test interrupted by watchdog.

The problem is that the root task priority is 0, and that now, 0 is a
priority with a special meaning. However, VxWorks priority range is from
0 to 255, not from 1 to 255.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Niklaus Giger]

Hi
Am Sonntag, 23. Dezember 2007 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
> 
> Are you sure these errors are related to Xenomai, do not you get the
> same errors if you build the kernel without Xenomai enabled ? Also,
> you should tell us which versions of Linux you used, and post a link to
> the kernel configuration.
> 
I tweaked the buildbot to also produce a link to the config used.
Is it better for you if I post only the link to a failed build like
http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/
or
http://ngiger.dyndns.org/buildbot/builders/ppc_q/builds/22

There you can by clicking on the link go to the stdio of the failing step 
to the standard output. You find also in the same step (or for the tqm case
in the step before) a link to 'config'.

On the same page you get also info about the revision and
branch used of the Xenomai tree. With the link to 'cmd2run' you
get info about which linux version the buildbot uses.

Aggregating all this information into one single page would demand 
quite some effort. I am at this moment not sure whether it is worth
the effort, but once running the tests on my board is incorporated
into the buildbot, I will take another look at this challenge.

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Niklaus Giger]

Am Sonntag, 23. Dezember 2007 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
>  > a) The simulator fails in two tests with the vxworks skins. In
>  > http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/1/steps/check_sim/logs/stdio
>  > you will find at the end the lines
>  > > Some problems were reported in:
>  > > vxworks->t010726-1::
>  > > vxworks->t010823-2::
>  > Going back one finds:
>  > > starting VxWorks services.
>  > > Xenoscope: lt-t010823-2: fatal in MvmIrq (time=30000718.974563):
>  > > test interrupted by watchdog.
>  > and
>  > > starting VxWorks services.
>  > > Xenoscope: lt-t010726-1: fatal in MvmIrq (time=30000718.974820):
>  > > test interrupted by watchdog.
> 
> The problem is that the root task priority is 0, and that now, 0 is a
> priority with a special meaning. However, VxWorks priority range is from
> 0 to 255, not from 1 to 255.
> 
Usually only the excTask runs with priority 0 on a vxWorks system. I would
therefore suggest that we forbid starting a vxworks task with priority 0.
If a error is returned and this exception is documented in
the doc/txt/vxworks-skin.txt I could live with it without any problems.

Thanks anyway for your explanation.

-- 
Niklaus Giger

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Paul]

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


Hi Niklaus

On Sunday 23 December 2007 16:47, Niklaus Giger wrote:
> > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
> > function 'lbmStartIO':
> > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2165:
> > error: too many arguments to function 'lbmIODone'
<snip>
> > /var/buildbot/slave/ppc_f/linux-2.6-xenomai/drivers/net/via-rhine.c:44:1:
> > error: unterminated #ifndef make[3]: *** [drivers/net/via-rhine.o] Error

Attached patch resolves the two above errors - I too fell foul of them with an 
unpatched build (along with a couple in the USB code).

> > /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
> > error: implicit declaration of function 'get_paca'

This one is from the Xenomai patch - get_paca is found in asm-powerpc/paca.h 
which is conditionally included when CONFIG_PPC64 is defined. I suspect line 
340 should read:

#if defined(CONFIG_IPIPE) && defined(CONFIG_PPC64)

It bit me at line 549 in arch/powerpc/kernel/smp.c...

Regards, Paul.



[-- Attachment #2: jfs_via-rhine_ppc-DENX.patch --]
[-- Type: text/x-diff, Size: 2077 bytes --]

index 0041343..8f30c85 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -41,7 +41,6 @@
 static int debug = 1;	/* 1 normal messages, 0 quiet .. 7 verbose. */
 static int max_interrupt_work = 20;
 
-#ifndef PKT_ALIGN
 /* Set the copy breakpoint for the copy-only-tiny-frames scheme.
    Setting to > 1518 effectively disables this feature. */
 #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
index b1d1926..45dc960 100644
--- a/drivers/usb/host/ehci-au1xxx.c
+++ b/drivers/usb/host/ehci-au1xxx.c
@@ -221,8 +221,8 @@ static const struct hc_driver ehci_au1xxx_hc_driver = {
 	.hub_status_data = ehci_hub_status_data,
 	.hub_control = ehci_hub_control,
 #ifdef	CONFIG_PM
-	.hub_suspend = ehci_hub_suspend,
-	.hub_resume = ehci_hub_resume,
+	.bus_suspend = ehci_bus_suspend,
+	.bus_resume = ehci_bus_resume,
 #endif
 };
 
index 463650e..c6f8599 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -73,8 +73,8 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
 	.hub_status_data = ehci_hub_status_data,
 	.hub_control = ehci_hub_control,
 #ifdef	CONFIG_PM
-	.hub_suspend = ehci_hub_suspend,
-	.hub_resume = ehci_hub_resume,
+	.bus_suspend = ehci_bus_suspend,
+	.bus_resume = ehci_bus_resume,
 #endif
 };
 
index 4f99b0e..1d40843 100644
--- a/drivers/usb/host/ehci-ppc-soc.c
+++ b/drivers/usb/host/ehci-ppc-soc.c
@@ -161,8 +161,8 @@ static const struct hc_driver ehci_ppc_soc_hc_driver = {
 	.hub_status_data = ehci_hub_status_data,
 	.hub_control = ehci_hub_control,
 #ifdef	CONFIG_PM
-	.hub_suspend = ehci_hub_suspend,
-	.hub_resume = ehci_hub_resume,
+	.bus_suspend = ehci_bus_suspend,
+	.bus_resume = ehci_bus_resume,
 #endif
 };
 
index 57c3b8a..59dbc5c 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2162,7 +2162,7 @@ static void lbmStartIO(struct lbuf * bp)
 	/* check if journaling to disk has been disabled */
 	if (log->no_integrity) {
 		bio->bi_size = 0;
-		lbmIODone(bio, 0, 0);
+		lbmIODone(bio, 0);
 	} else {
 		submit_bio(WRITE_SYNC, bio);
 		INCREMENT(lmStat.submitted);

Re: [Xenomai-core] Buildbot is back (and reporting errors)

[Philippe Gerum]

Paul wrote:
> Hi Niklaus
> 
> On Sunday 23 December 2007 16:47, Niklaus Giger wrote:
>>> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
>>> function 'lbmStartIO':
>>> /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2165:
>>> error: too many arguments to function 'lbmIODone'
> <snip>
>>> /var/buildbot/slave/ppc_f/linux-2.6-xenomai/drivers/net/via-rhine.c:44:1:
>>> error: unterminated #ifndef make[3]: *** [drivers/net/via-rhine.o] Error
> 
> Attached patch resolves the two above errors - I too fell foul of them with an 
> unpatched build (along with a couple in the USB code).
> 
>>> /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
>>> error: implicit declaration of function 'get_paca'
> 
> This one is from the Xenomai patch - get_paca is found in asm-powerpc/paca.h 
> which is conditionally included when CONFIG_PPC64 is defined. I suspect line 
> 340 should read:
> 
> #if defined(CONFIG_IPIPE) && defined(CONFIG_PPC64)
> 

This one is a left-over from the 2.6.23/powerpc/ to ppc/ backport. We
should have no hunk at this location, since we do not support SMP with
this backport anyway, only embedded uniprocessor 32bit platforms still
lagging behind the powerpc/ merge.

> It bit me at line 549 in arch/powerpc/kernel/smp.c...

Ok, fixed in the upcoming 2.0-06.

-- 
Philippe.