linux-next: sparc tree build failure

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's (and for a few days) linux-next build (sparc32 defconfig) failed
like this:

In file included from include2/asm/page.h:4,
                 from arch/sparc/kernel/vmlinux.lds.S:4:
include/asm-sparc/page_64.h:11:2: #error No page size specified in kernel configuration

Due to the merge of page.h (I suspect).  The patch below fixes it.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

>From 2c8b8ccd3bb14cf6100ba86411d7ef676cf974df Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Jul 2008 17:34:27 +1000
Subject: [PATCH] sparc32: pass -m32 when building vmlinux.lds

Otherwise it breaks since we merged asm/page.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index fef28e2..6668e60 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -18,6 +18,7 @@ CHECKFLAGS	+= -D__sparc__
 #KBUILD_CFLAGS += -g -pipe -fcall-used-g5 -fcall-used-g7
 KBUILD_CFLAGS += -m32 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
 KBUILD_AFLAGS += -m32
+CPPFLAGS_vmlinux.lds += -m32
 
 #LDFLAGS_vmlinux = -N -Ttext 0xf0004000
 #  Since 2.5.40, the first stage is left not btfix-ed.
-- 
1.5.6.3


[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Jul 2008 17:41:51 +1000

> Today's (and for a few days) linux-next build (sparc32 defconfig) failed
> like this:
> 
> In file included from include2/asm/page.h:4,
>                  from arch/sparc/kernel/vmlinux.lds.S:4:
> include/asm-sparc/page_64.h:11:2: #error No page size specified in kernel configuration
> 
> Due to the merge of page.h (I suspect).  The patch below fixes it.

Applied, thanks Stephen.

Re: linux-next: sparc tree build failure

[Thomas Gleixner]

On Thu, 26 Nov 2009, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 26 Nov 2009 20:16:07 +1100
> 
> > Today's linux-next build (sparc32 defconfig) failed like this:
> > 
> > arch/sparc/lib/atomic32.c: In function '__atomic_add_return':
> > arch/sparc/lib/atomic32.c:34: error: implicit declaration of function '__raw_spin_lock_irqsave'
> > arch/sparc/lib/atomic32.c:38: error: implicit declaration of function '__raw_spin_unlock_irqrestore'
> > 
> > Caused by commit 4df286e52917c95c415400367cfd523dfbb0f93a ("sparc: Make
> > atomic locks raw") which I have reverted for today.
> 
> Ho hum, that's the second iteration and it broke the build first time
> too.
> 
> __raw_spin_lock_irqsave() definitions don't exist anywhere in the
> tree, I wonder what this was even build tested against?
> 
> I'm reverting, and I'll be hard pressed to add new versions without
> solid proof that it doesn't break the build a third time :-)

/me blushes. Dunno what went wrong this time. Sorry.

    tglx

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 26 Nov 2009 20:16:07 +1100

> Today's linux-next build (sparc32 defconfig) failed like this:
> 
> arch/sparc/lib/atomic32.c: In function '__atomic_add_return':
> arch/sparc/lib/atomic32.c:34: error: implicit declaration of function '__raw_spin_lock_irqsave'
> arch/sparc/lib/atomic32.c:38: error: implicit declaration of function '__raw_spin_unlock_irqrestore'
> 
> Caused by commit 4df286e52917c95c415400367cfd523dfbb0f93a ("sparc: Make
> atomic locks raw") which I have reverted for today.

Ho hum, that's the second iteration and it broke the build first time
too.

__raw_spin_lock_irqsave() definitions don't exist anywhere in the
tree, I wonder what this was even build tested against?

I'm reverting, and I'll be hard pressed to add new versions without
solid proof that it doesn't break the build a third time :-)

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (sparc32 defconfig) failed like this:

arch/sparc/lib/atomic32.c: In function '__atomic_add_return':
arch/sparc/lib/atomic32.c:34: error: implicit declaration of function '__raw_spin_lock_irqsave'
arch/sparc/lib/atomic32.c:38: error: implicit declaration of function '__raw_spin_unlock_irqrestore'

Caused by commit 4df286e52917c95c415400367cfd523dfbb0f93a ("sparc: Make
atomic locks raw") which I have reverted for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

Your patch is correct but is whitespace damaged by your email
client.

Please take extra care to avoid this, because I spent the time to
prepare your patch for application and then it failed, and therefore I
wasted my time on your patch.

Re: linux-next: sparc tree build failure

[Kristoffer Glembo]

I noticed just now that this patch broke the driver on LEON SPARC. It
does not find the root node by using of_find_node_by_name(NULL, "/").

I'm not sure whether this is because we build our OF tree wrong or if
it is an incorrect way of doing things. But if I instead change it to
of_find_node_by_path("/") it works fine.

Signed-off-by: Kristoffer Glembo <kristoffer@gaisler.com>

---
  drivers/serial/apbuart.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/apbuart.c b/drivers/serial/apbuart.c
index a1e9503..fe91319 100644
--- a/drivers/serial/apbuart.c
+++ b/drivers/serial/apbuart.c
@@ -609,7 +609,7 @@ static void grlib_apbuart_configure(void)
                 return;

         /* Get bus frequency */
-       rp = of_find_node_by_name(NULL, "/");
+       rp = of_find_node_by_path("/");
         rp = of_get_next_child(rp, NULL);
         prop = of_get_property(rp, "clock-frequency", NULL);
         freq_khz = *prop;
--
1.5.2.2


David Miller wrote:
> 
> Hmm, it took a tiny bit more than that :-)  Here's what I commited
> to fix this, thanks.
> 
> apbuart: Kill dependency on deprecated Sparc-only PROM interfaces.
> 
> Use the proper modern OF ones instead.
> 
> Noticed by Stephen Rothwell.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  drivers/serial/apbuart.c |   12 ++++++------
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/serial/apbuart.c b/drivers/serial/apbuart.c
> index c7883a3..5f9dec3 100644
> --- a/drivers/serial/apbuart.c
> +++ b/drivers/serial/apbuart.c
> @@ -29,7 +29,6 @@
>  #include <linux/io.h>
>  #include <linux/serial_core.h>
>  #include <asm/irq.h>
> -#include <asm/oplib.h>
>  
>  #include "apbuart.h"
>  
> @@ -596,10 +595,9 @@ static struct of_platform_driver grlib_apbuart_of_driver = {
>  static void grlib_apbuart_configure(void)
>  {
>  	static int enum_done;
> -	struct device_node *np;
> +	struct device_node *np, *rp;
>  	struct uart_port *port = NULL;
> -
> -	int node;
> +	const u32 *prop;
>  	int freq_khz;
>  	int v = 0, d = 0;
>  	unsigned int addr;
> @@ -610,8 +608,10 @@ static void grlib_apbuart_configure(void)
>  		return;
>  
>  	/* Get bus frequency */
> -	node = prom_getchild(prom_root_node);
> -	freq_khz = prom_getint(node, "clock-frequency");
> +	rp = of_find_node_by_name(NULL, "/");
> +	rp = of_get_next_child(rp, NULL);
> +	prop = of_get_property(rp, "clock-frequency", NULL);
> +	freq_khz = *prop;
>  
>  	line = 0;
>  	for_each_matching_node(np, apbuart_match) {

Re: linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

On Fri, 06 Nov 2009 00:26:51 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> Stephen, can you let me know if this takes care of everything?

Sorry, sleep intervened :-)

That patch fixes the build of the .o (I didn't do the link).

Thanks.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Fri, 06 Nov 2009 00:26:51 -0800 (PST)

> apbuart: Fix build and missing driver unregister.
> 
> linux/of_platform.h needs to be included
> 
> OF driver needs to be unregistered
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>

Sorry left out the patch :-)

Here it is:

diff --git a/drivers/serial/apbuart.c b/drivers/serial/apbuart.c
index 5f9dec3..a1e9503 100644
--- a/drivers/serial/apbuart.c
+++ b/drivers/serial/apbuart.c
@@ -25,6 +25,7 @@
 #include <linux/device.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/serial_core.h>
@@ -676,8 +677,7 @@ static int __init grlib_apbuart_init(void)
 		return ret;
 	}
 
-	ret = of_register_driver(&grlib_apbuart_of_driver, &of_platform_bus_type);
-
+	ret = of_register_platform_driver(&grlib_apbuart_of_driver);
 	if (ret) {
 		printk(KERN_ERR
 		       "%s: of_register_platform_driver failed (%i)\n",
@@ -698,7 +698,7 @@ static void __exit grlib_apbuart_exit(void)
 				     &grlib_apbuart_ports[i]);
 
 	uart_unregister_driver(&grlib_apbuart_driver);
-
+	of_unregister_platform_driver(&grlib_apbuart_of_driver);
 }
 
 module_init(grlib_apbuart_init);
-- 
1.6.5.2

Re: linux-next: sparc tree build failure

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Fri, 06 Nov 2009 00:19:30 -0800 (PST)

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 6 Nov 2009 18:02:48 +1100
> 
>> Caused by commit d4ac42a582e46d7f86f0acb4253a310423c72c4c ("sparc:
>> Support for GRLIB APBUART serial port") (yes again :-)).  I have applied
>> my patch to make it only build on SPARC again ...
>> 
>> (Including linux/of_platform.h - where struct of_platform_driver,
>> of_register_driver() and of_platform_bus_type are declared - would be a
>> good start ...  and the code should probably be using
>> of_register_platform_driver() instead of of_register_driver() in any
>> case.)
> 
> Sorry, sparc is getting those headers indirectly.
> 
> I'll fix this up.

Stephen, can you let me know if this takes care of everything?

I also noticed that the of_driver was not being unregistered on
module unload.

apbuart: Fix build and missing driver unregister.

linux/of_platform.h needs to be included

OF driver needs to be unregistered

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 6 Nov 2009 18:02:48 +1100

> Caused by commit d4ac42a582e46d7f86f0acb4253a310423c72c4c ("sparc:
> Support for GRLIB APBUART serial port") (yes again :-)).  I have applied
> my patch to make it only build on SPARC again ...
> 
> (Including linux/of_platform.h - where struct of_platform_driver,
> of_register_driver() and of_platform_bus_type are declared - would be a
> good start ...  and the code should probably be using
> of_register_platform_driver() instead of of_register_driver() in any
> case.)

Sorry, sparc is getting those headers indirectly.

I'll fix this up.

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/serial/apbuart.c:585: error: variable 'grlib_apbuart_of_driver' has initializer but incomplete type
drivers/serial/apbuart.c:586: error: unknown field 'match_table' specified in initializer
drivers/serial/apbuart.c:586: warning: excess elements in struct initializer
drivers/serial/apbuart.c:586: warning: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c:587: error: unknown field 'probe' specified in initializer
drivers/serial/apbuart.c:587: warning: excess elements in struct initializer
drivers/serial/apbuart.c:587: warning: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c:588: error: unknown field 'driver' specified in initializer
drivers/serial/apbuart.c:588: error: extra brace group at end of initializer
drivers/serial/apbuart.c:588: error: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c:591: warning: excess elements in struct initializer
drivers/serial/apbuart.c:591: warning: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c: In function 'grlib_apbuart_init':
drivers/serial/apbuart.c:679: error: implicit declaration of function 'of_register_driver'
drivers/serial/apbuart.c:679: error: 'of_platform_bus_type' undeclared (first use in this function)

Caused by commit d4ac42a582e46d7f86f0acb4253a310423c72c4c ("sparc:
Support for GRLIB APBUART serial port") (yes again :-)).  I have applied
my patch to make it only build on SPARC again ...

(Including linux/of_platform.h - where struct of_platform_driver,
of_register_driver() and of_platform_bus_type are declared - would be a
good start ...  and the code should probably be using
of_register_platform_driver() instead of of_register_driver() in any
case.)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: linux-next: sparc tree build failure

[Kristoffer Glembo]

David Miller wrote:
> 
> Hmm, it took a tiny bit more than that :-)  Here's what I commited
> to fix this, thanks.
> 
> apbuart: Kill dependency on deprecated Sparc-only PROM interfaces.
> 
> Use the proper modern OF ones instead.
> 
> Noticed by Stephen Rothwell.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>

Thanks guys. Sorry for the obsolete code :-)

Best regards,
Kristoffer

Re: linux-next: sparc tree build failure

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Wed, 04 Nov 2009 23:53:15 -0800 (PST)

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 5 Nov 2009 18:50:14 +1100
> 
>> Caused by commit d4ac42a582e46d7f86f0acb4253a310423c72c4c ("sparc:
>> Support for GRLIB APBUART serial port").  I added the following patch for
>> today.
> 
> Thanks, the real fix is to simply remove that include, it isn't
> actually needed and the CONFIG_OF dependency is sufficient.

Hmm, it took a tiny bit more than that :-)  Here's what I commited
to fix this, thanks.

apbuart: Kill dependency on deprecated Sparc-only PROM interfaces.

Use the proper modern OF ones instead.

Noticed by Stephen Rothwell.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/serial/apbuart.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/serial/apbuart.c b/drivers/serial/apbuart.c
index c7883a3..5f9dec3 100644
--- a/drivers/serial/apbuart.c
+++ b/drivers/serial/apbuart.c
@@ -29,7 +29,6 @@
 #include <linux/io.h>
 #include <linux/serial_core.h>
 #include <asm/irq.h>
-#include <asm/oplib.h>
 
 #include "apbuart.h"
 
@@ -596,10 +595,9 @@ static struct of_platform_driver grlib_apbuart_of_driver = {
 static void grlib_apbuart_configure(void)
 {
 	static int enum_done;
-	struct device_node *np;
+	struct device_node *np, *rp;
 	struct uart_port *port = NULL;
-
-	int node;
+	const u32 *prop;
 	int freq_khz;
 	int v = 0, d = 0;
 	unsigned int addr;
@@ -610,8 +608,10 @@ static void grlib_apbuart_configure(void)
 		return;
 
 	/* Get bus frequency */
-	node = prom_getchild(prom_root_node);
-	freq_khz = prom_getint(node, "clock-frequency");
+	rp = of_find_node_by_name(NULL, "/");
+	rp = of_get_next_child(rp, NULL);
+	prop = of_get_property(rp, "clock-frequency", NULL);
+	freq_khz = *prop;
 
 	line = 0;
 	for_each_matching_node(np, apbuart_match) {
-- 
1.6.5.2

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Nov 2009 18:50:14 +1100

> Caused by commit d4ac42a582e46d7f86f0acb4253a310423c72c4c ("sparc:
> Support for GRLIB APBUART serial port").  I added the following patch for
> today.

Thanks, the real fix is to simply remove that include, it isn't
actually needed and the CONFIG_OF dependency is sufficient.

linux-next: sparc tree build failure

[Stephen Rothwell]

Hi Dave,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/serial/apbuart.c:32:23: error: asm/oplib.h: No such file or directory
drivers/serial/apbuart.c:586: error: variable 'grlib_apbuart_of_driver' has initializer but incomplete type
drivers/serial/apbuart.c:587: error: unknown field 'match_table' specified in initializer
drivers/serial/apbuart.c:587: warning: excess elements in struct initializer
drivers/serial/apbuart.c:587: warning: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c:588: error: unknown field 'probe' specified in initializer
drivers/serial/apbuart.c:588: warning: excess elements in struct initializer
drivers/serial/apbuart.c:588: warning: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c:589: error: unknown field 'driver' specified in initializer
drivers/serial/apbuart.c:589: error: extra brace group at end of initializer
drivers/serial/apbuart.c:589: error: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c:592: warning: excess elements in struct initializer
drivers/serial/apbuart.c:592: warning: (near initialization for 'grlib_apbuart_of_driver')
drivers/serial/apbuart.c: In function 'grlib_apbuart_configure':
drivers/serial/apbuart.c:613: error: implicit declaration of function 'prom_getchild'
drivers/serial/apbuart.c:613: error: 'prom_root_node' undeclared (first use in this function)
drivers/serial/apbuart.c:613: error: (Each undeclared identifier is reported only once
drivers/serial/apbuart.c:613: error: for each function it appears in.)
drivers/serial/apbuart.c:614: error: implicit declaration of function 'prom_getint'
drivers/serial/apbuart.c: In function 'grlib_apbuart_init':
drivers/serial/apbuart.c:679: error: implicit declaration of function 'of_register_driver'
drivers/serial/apbuart.c:679: error: 'of_platform_bus_type' undeclared (first use in this function)

Caused by commit d4ac42a582e46d7f86f0acb4253a310423c72c4c ("sparc:
Support for GRLIB APBUART serial port").  I added the following patch for
today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Nov 2009 18:40:55 +1100
Subject: [PATCH] sparc: the GRLIB APBUART serial port will only build on sparc

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/serial/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 50943ff..7ec806d 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1480,6 +1480,7 @@ config SERIAL_BCM63XX_CONSOLE
 config SERIAL_GRLIB_GAISLER_APBUART
 	tristate "GRLIB APBUART serial support"
 	depends on OF
+	depends on SPARC
 	---help---
 	Add support for the GRLIB APBUART serial port.
 
-- 
1.6.5.2


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 5 Oct 2009 18:43:57 +1100

> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> arch/sparc/oprofile/init.c: In function 'timer_start':
> arch/sparc/oprofile/init.c:46: error: 'HZ' undeclared (first use in this function)
> 
> I have no idea why this just cropped up, but I have added the following
> patch for today.

I suspect:

commit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Sun Oct 4 16:11:37 2009 +0400

    headers: remove sched.h from poll.h
    
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

I'll add your fix to sparc-2.6, thanks!

linux-next: sparc tree build failure

[Stephen Rothwell]

Hi Dave,

Today's linux-next build (sparc64 defconfig) failed like this:

arch/sparc/oprofile/init.c: In function 'timer_start':
arch/sparc/oprofile/init.c:46: error: 'HZ' undeclared (first use in this function)

I have no idea why this just cropped up, but I have added the following
patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 5 Oct 2009 18:32:33 +1100
Subject: [PATCH] sparc: using HZ needs an include of linux/param.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/oprofile/init.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/sparc/oprofile/init.c b/arch/sparc/oprofile/init.c
index f97cb8b..62f4120 100644
--- a/arch/sparc/oprofile/init.c
+++ b/arch/sparc/oprofile/init.c
@@ -11,7 +11,8 @@
 #include <linux/oprofile.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/param.h>	/* for HZ */
  
 #ifdef CONFIG_SPARC64
 #include <linux/notifier.h>
 #include <linux/rcupdate.h>
-- 
1.6.4.3


-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi all,

On Thu, 9 Apr 2009 15:17:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> arch/sparc/kernel/built-in.o: In function `trap_init':
> (.init.text+0x4): undefined reference to `thread_info_offsets_are_bolixed_dave'
> 
> Caused by commit 52400ba946759af28442dee6265c5c0180ac7122 ("futex: add
> requeue_pi functionality") (from the tip-core tree) which changed the
> size of struct restart_block.

This is still happening except the actual error has changed (due to the new BUILD_BUG_ON):

arch/sparc/kernel/traps_64.c: In function 'trap_init':
arch/sparc/kernel/traps_64.c:2534: error: size of array 'type name' is negative

I applied the same patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 9 Apr 2009 07:53:56 +0200

> We could create a standalone, .30-rc1 based topic for the 
> linux/thread_info.h change only, and push it to Linus, and/or you 
> could pull it into the Sparc tree?

Actually, it turns out I'm changing different structure offsets in the
sparc64 dynamic per-cpu changes.  There shouldn't be any thread_info.h
conflicts, therefore.

So you can take the sparc64 build fix patch in your tree, that's fine.

Thanks!

Re: linux-next: sparc tree build failure

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Thu, 9 Apr 2009 07:36:30 +0200
> 
> > Would it be possible for you to reserve the extra futex related 
> > pointer right now? (or is that not possible without changing the 
> > restart block in linux/thread_info.h?)
> 
> What are my real options?
> 
> No matter what, once you change the size of "struct restart_block" 
> the sparc64 build will fail, no matter what.
> 
> The only way around this is if you merge the thing that changes 
> the "struct restart_block"'s size to Linus now along with the 
> sparc64 change at the same time.
> 
> But then I have a merge issue I have to resolve in the sparc64 
> tree because I've already pushed out my dynamic per-cpu work
> :-/

We could create a standalone, .30-rc1 based topic for the 
linux/thread_info.h change only, and push it to Linus, and/or you 
could pull it into the Sparc tree?

	Ingo

Re: linux-next: sparc tree build failure

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 9 Apr 2009 07:36:30 +0200

> Would it be possible for you to reserve the extra futex related 
> pointer right now? (or is that not possible without changing the 
> restart block in linux/thread_info.h?)

What are my real options?

No matter what, once you change the size of "struct restart_block"
the sparc64 build will fail, no matter what.

The only way around this is if you merge the thing that changes
the "struct restart_block"'s size to Linus now along with the
sparc64 change at the same time.

But then I have a merge issue I have to resolve in the sparc64
tree because I've already pushed out my dynamic per-cpu work
:-/

Grumble...

Re: linux-next: sparc tree build failure

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Thu, 9 Apr 2009 07:27:17 +0200
> 
> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> >> Hi all,
> >> 
> >> Today's linux-next build (sparc64 defconfig) failed like this:
> >> 
> >> arch/sparc/kernel/built-in.o: In function `trap_init':
> >> (.init.text+0x4): undefined reference to `thread_info_offsets_are_bolixed_dave'
> >> 
> >> Caused by commit 52400ba946759af28442dee6265c5c0180ac7122 ("futex: add
> >> requeue_pi functionality") (from the tip-core tree) which changed the
> >> size of struct restart_block.
> >> 
> >> Dave, this might be a good time to suggest that sparc64 create its TI_
> >> offsets automatically via asm-offsets ...
> >> 
> >> I applied the following patch for today.
> > 
> > David, would it be appropriate for us to queue up Stephen's fix 
> > in the futex tree, so that any rewrite can be decoupled from 
> > these changes and the Sparc tree would still work as well?
> 
> Yes, but it's going to conflict with the dynamic per-cpu work I'm 
> doing in the sparc-next tree right now.

Would it be possible for you to reserve the extra futex related 
pointer right now? (or is that not possible without changing the 
restart block in linux/thread_info.h?)

Last i checked the futex changes looked pretty ready: queued up for 
.31, they were ABI-acked by Ulrich, Roland, etc. and were tested 
through - so there's no additional churn or reverts / disappearing 
commits expected. (Thomas please confirm that this is indeed so.)

That way then when Stephen resolves the conflict then the futex tree 
change is overriden with your changes in the Sparc tree.

That will make it all bisectable as well - should anyone ever have 
the need to bisect down into that set of commits.

	Ingo

Re: linux-next: sparc tree build failure

[David Miller]

From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 9 Apr 2009 07:27:17 +0200

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi all,
>> 
>> Today's linux-next build (sparc64 defconfig) failed like this:
>> 
>> arch/sparc/kernel/built-in.o: In function `trap_init':
>> (.init.text+0x4): undefined reference to `thread_info_offsets_are_bolixed_dave'
>> 
>> Caused by commit 52400ba946759af28442dee6265c5c0180ac7122 ("futex: add
>> requeue_pi functionality") (from the tip-core tree) which changed the
>> size of struct restart_block.
>> 
>> Dave, this might be a good time to suggest that sparc64 create its TI_
>> offsets automatically via asm-offsets ...
>> 
>> I applied the following patch for today.
> 
> David, would it be appropriate for us to queue up Stephen's fix in 
> the futex tree, so that any rewrite can be decoupled from these 
> changes and the Sparc tree would still work as well?

Yes, but it's going to conflict with the dynamic per-cpu work
I'm doing in the sparc-next tree right now.

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 9 Apr 2009 15:17:22 +1000

> Dave, this might be a good time to suggest that sparc64 create its TI_
> offsets automatically via asm-offsets ...

I want to know the exact offsets for cache layout reasons,
at the very least.  And there are other more important reasons
to check this stuff out by hand and don't let it compile
automatically.

Anything that changes the layout and size of members in struct
thread_info should be scrutinized carefully by every arch maintainer.

There are other implications for these kinds of changes, for example
this decreases the amount of space we have to save our recursive
kernel/user FPU state on sparc64.

I don't want any of this to be automated at all.

Re: linux-next: sparc tree build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> arch/sparc/kernel/built-in.o: In function `trap_init':
> (.init.text+0x4): undefined reference to `thread_info_offsets_are_bolixed_dave'
> 
> Caused by commit 52400ba946759af28442dee6265c5c0180ac7122 ("futex: add
> requeue_pi functionality") (from the tip-core tree) which changed the
> size of struct restart_block.
> 
> Dave, this might be a good time to suggest that sparc64 create its TI_
> offsets automatically via asm-offsets ...
> 
> I applied the following patch for today.

David, would it be appropriate for us to queue up Stephen's fix in 
the futex tree, so that any rewrite can be decoupled from these 
changes and the Sparc tree would still work as well?

	Ingo

linux-next: sparc tree build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (sparc64 defconfig) failed like this:

arch/sparc/kernel/built-in.o: In function `trap_init':
(.init.text+0x4): undefined reference to `thread_info_offsets_are_bolixed_dave'

Caused by commit 52400ba946759af28442dee6265c5c0180ac7122 ("futex: add
requeue_pi functionality") (from the tip-core tree) which changed the
size of struct restart_block.

Dave, this might be a good time to suggest that sparc64 create its TI_
offsets automatically via asm-offsets ...

I applied the following patch for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

>From 11f2623cf0416509193865acad7e36ae05e31b1a Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 9 Apr 2009 15:12:38 +1000
Subject: [PATCH] sparc64: update for restart_block size change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/include/asm/thread_info_64.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
index 639ac80..6586572 100644
--- a/arch/sparc/include/asm/thread_info_64.h
+++ b/arch/sparc/include/asm/thread_info_64.h
@@ -102,8 +102,8 @@ struct thread_info {
 #define TI_KERN_CNTD1	0x00000488
 #define TI_PCR		0x00000490
 #define TI_RESTART_BLOCK 0x00000498
-#define TI_KUNA_REGS	0x000004c0
-#define TI_KUNA_INSN	0x000004c8
+#define TI_KUNA_REGS	0x000004c8
+#define TI_KUNA_INSN	0x000004d0
 #define TI_FPREGS	0x00000500
 
 /* We embed this in the uppermost byte of thread_info->flags */
-- 
1.6.2.1

Re: linux-next: sparc tree build failure

[Sam Ravnborg]

On Thu, Dec 04, 2008 at 07:54:24PM +1100, Stephen Rothwell wrote:
> Hi Dave,
> 
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/basic/docproc
>   HOSTCC  scripts/basic/hash
>   GEN     /scratch/sfr/sparc64_defconfig/Makefile
>   HOSTCC  scripts/kconfig/conf.o
>   HOSTCC  scripts/kconfig/kxgettext.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/lex.zconf.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> *** Default configuration is based on 'sparc64_defconfig'
> ***
> *** Can't find default configuration "arch/sparc/configs/sparc64_defconfig"!
> ***
> 
> Caused, I suspect by commit 60f2e8ffcf7291fc7df05dd91caf84d75c5181c5
> ("sparc,sparc64: unify Makefile") which I reverted (along with
> commit 9251dc5153ee5dae27e81835a35f3b7c0a73259e "sparc,sparc64: unify
> prom/" which depended on it).

The defconfig files got lost - you will see same issue with sparc(32).
The easy fix is to add them again from an older tree.

The are named sparc32_defconfig and sparc64_defconfig

This has no bisect impact as only "make defconfig" is faulty
so no need to consider renasing the tree.

	Sam

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (sparc64 defconfig) failed like this:

  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/basic/hash
  GEN     /scratch/sfr/sparc64_defconfig/Makefile
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/lex.zconf.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'sparc64_defconfig'
***
*** Can't find default configuration "arch/sparc/configs/sparc64_defconfig"!
***

Caused, I suspect by commit 60f2e8ffcf7291fc7df05dd91caf84d75c5181c5
("sparc,sparc64: unify Makefile") which I reverted (along with
commit 9251dc5153ee5dae27e81835a35f3b7c0a73259e "sparc,sparc64: unify
prom/" which depended on it).  But that just got me to this error:

cc1: fatal error: opening output file arch/sparc64/kernel/../../sparc/kernel/vmlinux.lds: No such file or directory

(I build in a separate object directory.)

So I reverted the whole sparc tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: Rusty Russell <rusty@rustcorp.com.au>
Date: Tue, 2 Dec 2008 21:52:25 +1030

> On Tuesday 02 December 2008 16:54:13 Stephen Rothwell wrote:
> > Hi Dave,
> >
> > Today's linux-next build (sparc defconfig) failed like this:
> >
> > lib/find_next_bit.c: In function 'find_last_bit':
> > lib/find_next_bit.c:183: error: implicit declaration of function '__fls'
> 
> Thanks Stephen... that's a surprise.
> 
> Dave, I think this is a sparc issue.
> 
> sparc: asm/bitops.h should define __fls

I'll add this patch, thanks Rusty.

Re: linux-next: sparc tree build failure

[Rusty Russell]

On Tuesday 02 December 2008 16:54:13 Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (sparc defconfig) failed like this:
>
> lib/find_next_bit.c: In function 'find_last_bit':
> lib/find_next_bit.c:183: error: implicit declaration of function '__fls'

Thanks Stephen... that's a surprise.

Dave, I think this is a sparc issue.

sparc: asm/bitops.h should define __fls

bitops_64.h includes the generic one; pretty sure 32 should too.

(Found by using __fls in generic code and breaking sparc defconfig build:
 thanks Stephen and linux-next!)

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff --git a/arch/sparc/include/asm/bitops_32.h b/arch/sparc/include/asm/bitops_32.h
--- a/arch/sparc/include/asm/bitops_32.h
+++ b/arch/sparc/include/asm/bitops_32.h
@@ -98,6 +98,7 @@ static inline void change_bit(unsigned l
 #include <asm-generic/bitops/sched.h>
 #include <asm-generic/bitops/ffs.h>
 #include <asm-generic/bitops/fls.h>
+#include <asm-generic/bitops/__fls.h>
 #include <asm-generic/bitops/fls64.h>
 #include <asm-generic/bitops/hweight.h>
 #include <asm-generic/bitops/lock.h>

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (sparc defconfig) failed like this:

lib/find_next_bit.c: In function 'find_last_bit':
lib/find_next_bit.c:183: error: implicit declaration of function '__fls'

Caused by commit 352102898a13616e6f9248c38ffe6dbf9ed4016b
("bitmap:find_last_bit") from the rr tree.  I have reverted that commit
along with commit b2db63a70fbc9da9ce6da1331f61db9dde51bcce
("cpumask:use-find_last_bit") which depended on it.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Mon, 1 Dec 2008 06:41:40 +0100

> On Mon, Dec 01, 2008 at 10:46:39AM +1100, Stephen Rothwell wrote:
> > Hi Dave,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> >   GEN     /scratch/sfr/powerpc_ppc64_defconfig/Makefile
> > ***
> > *** Can't find default configuration "arch/sparc/configs/ppc64_defconfig"!
> > ***
> > 
> > Caused by commit 9cdcf85e1bf5dca97c1304292810041af2fcbd42 ("Subject:
> > [PATCH 08/10] sparc,sparc64: unify Makefile") which seems to arbitrarily
> > set SRCARCH in the top level make file to sparc!
> Crap - missed an if/endif
> Fix is simple:

Applied, thanks Sam.

World sparc domination almost worked :)

Re: linux-next: sparc tree build failure

[Sam Ravnborg]

On Mon, Dec 01, 2008 at 10:46:39AM +1100, Stephen Rothwell wrote:
> Hi Dave,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
>   GEN     /scratch/sfr/powerpc_ppc64_defconfig/Makefile
> ***
> *** Can't find default configuration "arch/sparc/configs/ppc64_defconfig"!
> ***
> 
> Caused by commit 9cdcf85e1bf5dca97c1304292810041af2fcbd42 ("Subject:
> [PATCH 08/10] sparc,sparc64: unify Makefile") which seems to arbitrarily
> set SRCARCH in the top level make file to sparc!
Crap - missed an if/endif
Fix is simple:
diff --git a/Makefile b/Makefile
index 0043224..45f4300 100644
--- a/Makefile
+++ b/Makefile
@@ -206,7 +206,9 @@ ifeq ($(ARCH),x86_64)
 endif
 
 # Additional ARCH settings for sparc
+ifeq ($(ARCH),sparc64)
        SRCARCH := sparc
+endif
 
 # Where to locate arch specific headers
 hdr-arch  := $(SRCARCH)

> 
> (One way to take over the world, I guess :-))
Reminds me about Pinky & Brain - we almost suceeded!

	Sam

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

  GEN     /scratch/sfr/powerpc_ppc64_defconfig/Makefile
***
*** Can't find default configuration "arch/sparc/configs/ppc64_defconfig"!
***

Caused by commit 9cdcf85e1bf5dca97c1304292810041af2fcbd42 ("Subject:
[PATCH 08/10] sparc,sparc64: unify Makefile") which seems to arbitrarily
set SRCARCH in the top level make file to sparc!

(One way to take over the world, I guess :-))

I have dropped the sparc tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

On Sun, 03 Aug 2008 21:26:20 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 25 Jul 2008 17:05:27 +1000
> 
> > Hi Dave,
> > 
> > Today's linux-next build (sparc defconfig) failed like this:
> > 
> >   Building modules, stage 2.
> > .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> 
> FWIW, Sam had narrowed it down to:
> 
> commit fd593d12770d4a0d1ff095d44b96436c18479ee8
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date:   Thu Dec 7 02:14:04 2006 +0100
> 
>     [PATCH] relocatable kernel: Kallsyms generate relocatable symbols
>     
>     Print the addresses of non-absolute symbols relative to _text
>     so that ld will generate relocations.  Allowing a relocatable
>     kernel to relocate them.  We can't actually use the symbol names
>     because kallsyms includes static symbols that are not exported
>     from their object files.
>     
>     Add the _text symbol definitions to the architectures which don't
>     define it otherwise linker will fail.
>     
>     Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>     Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
>     Signed-off-by: Andi Kleen <ak@suse.de>
> 
> and
> 
> commit 2c22d8baa98a92022acb85b0b7c6f4a60df55f47
> Author: Vivek Goyal <vgoyal@in.ibm.com>
> Date:   Thu Dec 7 02:14:10 2006 +0100
> 
>     [PATCH] relocatable kernel: Fix kallsyms on avr32 after relocatable kernel changes
>     
>     o On some platforms like avr32, section init comes before .text and
>       not necessarily a symbol's relative position w.r.t _text is positive.
>       In such cases assembler detects the overflow and emits warning. This
>       patch fixes it.
>     
>     Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
>     Signed-off-by: Andi Kleen <ak@suse.de>
>     Cc: Andi Kleen <ak@suse.de>
>     Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
>     Signed-off-by: Andrew Morton <akpm@osdl.org>
> 
> but I personally still can't reproduce this.  I even had the gcc-3.4.5
> that's installed on my box, using defconfig just like you, and I can't
> trigger this problem.

Weird because I tracked it down to the following:

I finally bisected it down to this commit:

commit f9247273cb69ba101877e946d2d83044409cc8c5
Author: Steven Whitehouse <swhiteho@redhat.com>
Date:   Thu Jul 24 17:22:13 2008 +0100

    UFS: add const to parser token table


(I sent you an email about this on July 31.)
If I revert this and the followup commit:

commit fb2e405fc1fc8b20d9c78eaa1c7fd5a297efde43
Author: Adrian Bunk <bunk@kernel.org>
Date:   Fri Jul 25 02:55:49 2008 +0300

    fix fs/nfs/nfsroot.c compilation

the build succeeds.  Though I must admit Sam's culprits look more likely.

Also weird because I first saw this on July 25 (commit
f9247273cb69ba101877e946d2d83044409cc8c5 first appeared in linux-next
(via Linus' tree) on that day).  It could be some interaction between the
two sets of patches.

Weirder yet, my build system (kisskb) never got this failure even though
it uses the same toolchain that I used.

I just tried again and reverting the two patches I mentioned above does
make the failure go away.

Steve Whitehouse and Andrew asked Linus to revert those two patches but
nothing has happened yet.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 25 Jul 2008 17:05:27 +1000

> Hi Dave,
> 
> Today's linux-next build (sparc defconfig) failed like this:
> 
>   Building modules, stage 2.
> .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
> : relocation truncated to fit: R_SPARC_32 _text

FWIW, Sam had narrowed it down to:

commit fd593d12770d4a0d1ff095d44b96436c18479ee8
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Dec 7 02:14:04 2006 +0100

    [PATCH] relocatable kernel: Kallsyms generate relocatable symbols
    
    Print the addresses of non-absolute symbols relative to _text
    so that ld will generate relocations.  Allowing a relocatable
    kernel to relocate them.  We can't actually use the symbol names
    because kallsyms includes static symbols that are not exported
    from their object files.
    
    Add the _text symbol definitions to the architectures which don't
    define it otherwise linker will fail.
    
    Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
    Signed-off-by: Andi Kleen <ak@suse.de>

and

commit 2c22d8baa98a92022acb85b0b7c6f4a60df55f47
Author: Vivek Goyal <vgoyal@in.ibm.com>
Date:   Thu Dec 7 02:14:10 2006 +0100

    [PATCH] relocatable kernel: Fix kallsyms on avr32 after relocatable kernel changes
    
    o On some platforms like avr32, section init comes before .text and
      not necessarily a symbol's relative position w.r.t _text is positive.
      In such cases assembler detects the overflow and emits warning. This
      patch fixes it.
    
    Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
    Signed-off-by: Andi Kleen <ak@suse.de>
    Cc: Andi Kleen <ak@suse.de>
    Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
    Signed-off-by: Andrew Morton <akpm@osdl.org>

but I personally still can't reproduce this.  I even had the gcc-3.4.5
that's installed on my box, using defconfig just like you, and I can't
trigger this problem.

Re: linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Adrian,

On Mon, 28 Jul 2008 12:31:02 +0300 Adrian Bunk <bunk@kernel.org> wrote:
>
> I can also reproduce it (triggered by CONFIG_HEADERS_CHECK=y):
> 
> ...
> make -rR -f /tmp/linux-next-20080728/scripts/Makefile.headersinst 
> obj=include/drm dst=include/drm
>   perl scripts/headers_check.pl /tmp/linux-next-20080728/usr/include sparc64 /tmp/linux-next-20080728/usr/include/drm/drm.h /tmp/linux-next-20080728/usr/include/drm/drm_sarea.h /tmp/linux-next-20080728/usr/include/drm/i810_drm.h /tmp/linux-next-20080728/usr/include/drm/i830_drm.h /tmp/linux-next-20080728/usr/include/drm/i915_drm.h /tmp/linux-next-20080728/usr/include/drm/mga_drm.h /tmp/linux-next-20080728/usr/include/drm/r128_drm.h /tmp/linux-next-20080728/usr/include/drm/radeon_drm.h /tmp/linux-next-20080728/usr/include/drm/savage_drm.h /tmp/linux-next-20080728/usr/include/drm/sis_drm.h /tmp/linux-next-20080728/usr/include/drm/via_drm.h; touch /tmp/linux-next-20080728/usr/include/drm/.check
> /tmp/linux-next-20080728/usr/include/drm/drm.h:40: included file 'asm-sparc64/ioctl.h' is not exported
> make[3]: *** [/tmp/linux-next-20080728/usr/include/drm/.check] Error 1

Thanks.  My cross compiler completely failed me :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[Sam Ravnborg]

On Mon, Jul 28, 2008 at 08:12:14PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> On Mon, 28 Jul 2008 10:21:14 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > I cannot reproduce it here...
> > Can you try to delete rm -rf usr/include/ and build again.
> 
> These builds always start with a completely empty object directory.
> 
> > If it continue to happen then try to send me a "make V=1" output.
> 
> Its happened every build since 20080723 ... but I will try to get a V=1
> build.
OK - then it is the old breakage.
I had to break headers_check for a while when merging
the header files for sparc and sparc64.
This is now done and patches are in davem's sparc-next and
a pull request are sent to Linus.

So expect this breakage to be fixed next time you pull (assuming
you pull in sparc-next or Linus pulls in from davem).

Sorry for the hassle it has gving you - but I could not work out
a way that avoided the breakage.

	Sam

Re: linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Sam,

On Mon, 28 Jul 2008 10:21:14 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> I cannot reproduce it here...
> Can you try to delete rm -rf usr/include/ and build again.

These builds always start with a completely empty object directory.

> If it continue to happen then try to send me a "make V=1" output.

Its happened every build since 20080723 ... but I will try to get a V=1
build.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[Adrian Bunk]

On Mon, Jul 28, 2008 at 10:21:14AM +0200, Sam Ravnborg wrote:
> On Mon, Jul 28, 2008 at 04:38:08PM +1000, Stephen Rothwell wrote:
> > Hi Dave,
> > 
> > Today's linux-next build (sparc64 allmodconfig) failed like this:
> > 
> > usr/include/drm/drm.h:40: included file 'asm-sparc64/ioctl.h' is not exported
> > usr/include/video/sisfb.h:24: included file 'asm-sparc64/ioctl.h' is not exported
> > usr/include/video/sisfb.h:25: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/dvb/dmx.h:27: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/dvb/frontend.h:29: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/dvb/net.h:27: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/dvb/video.h:29: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/nfsd/export.h:13: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/nfsd/nfsfh.h:17: included file 'asm-sparc64/types.h' is not exported
> > usr/include/linux/nfsd/syscall.h:12: included file 'asm-sparc64/types.h' is not exported
> > 
> > This has been happening since (at least) next-20080723.
> 
> I cannot reproduce it here...
> Can you try to delete rm -rf usr/include/ and build again.
> If it continue to happen then try to send me a "make V=1" output.

I can also reproduce it (triggered by CONFIG_HEADERS_CHECK=y):

...
make -rR -f /tmp/linux-next-20080728/scripts/Makefile.headersinst 
obj=include/drm dst=include/drm
  perl scripts/headers_check.pl /tmp/linux-next-20080728/usr/include sparc64 /tmp/linux-next-20080728/usr/include/drm/drm.h /tmp/linux-next-20080728/usr/include/drm/drm_sarea.h /tmp/linux-next-20080728/usr/include/drm/i810_drm.h /tmp/linux-next-20080728/usr/include/drm/i830_drm.h /tmp/linux-next-20080728/usr/include/drm/i915_drm.h /tmp/linux-next-20080728/usr/include/drm/mga_drm.h /tmp/linux-next-20080728/usr/include/drm/r128_drm.h /tmp/linux-next-20080728/usr/include/drm/radeon_drm.h /tmp/linux-next-20080728/usr/include/drm/savage_drm.h /tmp/linux-next-20080728/usr/include/drm/sis_drm.h /tmp/linux-next-20080728/usr/include/drm/via_drm.h; touch /tmp/linux-next-20080728/usr/include/drm/.check
/tmp/linux-next-20080728/usr/include/drm/drm.h:40: included file 'asm-sparc64/ioctl.h' is not exported
make[3]: *** [/tmp/linux-next-20080728/usr/include/drm/.check] Error 1

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: linux-next: sparc tree build failure

[Sam Ravnborg]

On Mon, Jul 28, 2008 at 04:38:08PM +1000, Stephen Rothwell wrote:
> Hi Dave,
> 
> Today's linux-next build (sparc64 allmodconfig) failed like this:
> 
> usr/include/drm/drm.h:40: included file 'asm-sparc64/ioctl.h' is not exported
> usr/include/video/sisfb.h:24: included file 'asm-sparc64/ioctl.h' is not exported
> usr/include/video/sisfb.h:25: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/dvb/dmx.h:27: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/dvb/frontend.h:29: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/dvb/net.h:27: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/dvb/video.h:29: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/nfsd/export.h:13: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/nfsd/nfsfh.h:17: included file 'asm-sparc64/types.h' is not exported
> usr/include/linux/nfsd/syscall.h:12: included file 'asm-sparc64/types.h' is not exported
> 
> This has been happening since (at least) next-20080723.

I cannot reproduce it here...
Can you try to delete rm -rf usr/include/ and build again.
If it continue to happen then try to send me a "make V=1" output.

	Sam

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (sparc64 allmodconfig) failed like this:

usr/include/drm/drm.h:40: included file 'asm-sparc64/ioctl.h' is not exported
usr/include/video/sisfb.h:24: included file 'asm-sparc64/ioctl.h' is not exported
usr/include/video/sisfb.h:25: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/dvb/dmx.h:27: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/dvb/frontend.h:29: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/dvb/net.h:27: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/dvb/video.h:29: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/nfsd/export.h:13: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/nfsd/nfsfh.h:17: included file 'asm-sparc64/types.h' is not exported
usr/include/linux/nfsd/syscall.h:12: included file 'asm-sparc64/types.h' is not exported

This has been happening since (at least) next-20080723.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: sparc tree build failure

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 25 Jul 2008 17:05:27 +1000

> Today's linux-next build (sparc defconfig) failed like this:
> 
>   Building modules, stage 2.
> .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
> : relocation truncated to fit: R_SPARC_32 _text

That's impressive, getting a relocation overflow for
a 32-bit relocation on a 32-bit platforms, amazing!
:-)

I'll try to figure out whats wrong if someone else
doesn't beat me to it.

Re: linux-next: sparc tree build failure

[Stephen Rothwell]

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

On Fri, 25 Jul 2008 17:05:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (sparc defconfig) failed like this:

This was after I had merged all the trees into linux-next.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: sparc tree build failure

[Stephen Rothwell]

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

Hi Dave,

Today's linux-next build (sparc defconfig) failed like this:

  Building modules, stage 2.
.tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x4): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x8): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0xc): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x10): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x14): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x18): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x1c): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x20): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x24): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x28): In function `kallsyms_addresses':
: additional relocation overflows omitted from the output

Sorry, I have no idea how to fix this.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]