Re: linux-next: kbuild tree build failure

From: Michael Ellerman <michael@ellerman.id.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Paul Mackerras <paulus@samba.org>,
	linux-next@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
	linuxppc-dev@ozlabs.org
Subject: Re: linux-next: kbuild tree build failure
Date: Tue, 08 Jul 2008 09:36:38 +1000	[thread overview]
Message-ID: <1215473798.8138.4.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0807071424240.6791@localhost.localdomain>

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

On Mon, 2008-07-07 at 18:13 +0200, Roman Zippel wrote:
> Hi,
> 
> On Mon, 7 Jul 2008, Stephen Rothwell wrote:
> 
> > Hi Sam,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
> 
> I guess there also has been a kconfig warning somewhere. :)
> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to 
> standardize on 32bit values, as it doesn't really make sense to expect 
> from the user to input full 64bit values and it's easy to generate the 
> full value in a header. This would also ease on any portability issues 
> (kconfig is compiled with the host compiler not the target compiler).

Hi Roman,

I don't really see why it "doesn't make sense" for users to input 64-bit
values, they're configuring addresses for a 64-bit kernel, so some of
the values are going to be 64 bit.

Perhaps all the current values can be generated by shifting 32-bit
constants, but that seems like a hack to me.

Another comment below ..

> Index: linux-2.6/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/Kconfig
> +++ linux-2.6/arch/powerpc/Kconfig
> @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
>  
>  config PHYSICAL_START
>  	hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> -	default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> -	default "0x00000000"
> +	default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> +	default "0"
>  
>  config PHYSICAL_ALIGN
>  	hex
> @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
>  
>  config CONSISTENT_SIZE
>  	hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> -	default "0x00200000" if NOT_COHERENT_CACHE
> +	default "0x200000" if NOT_COHERENT_CACHE
>  
>  config PIN_TLB
>  	bool "Pinned Kernel TLBs (860 ONLY)"
> @@ -773,15 +773,11 @@ endmenu
>  if PPC64
>  config PAGE_OFFSET
>  	hex
> -	default "0xc000000000000000"
> -config KERNEL_START
> -	hex
> -	default "0xc000000002000000" if CRASH_DUMP
> -	default "0xc000000000000000"
> +	default "0xc0000000"

I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
config changes for the worse when I apply your patch and regenerate my
config:

--- .config.orig	2008-07-08 09:30:00.000000000 +1000
+++ .config	2008-07-08 09:30:43.000000000 +1000
@@ -370,9 +370,8 @@
 CONFIG_HOTPLUG_PCI_RPA=m
 CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
 # CONFIG_HAS_RAPIDIO is not set
-CONFIG_PAGE_OFFSET=0xc000000000000000
-CONFIG_KERNEL_START=0xc000000002000000
-CONFIG_PHYSICAL_START=0x02000000
+CONFIG_PAGE_OFFSET=0xc0000000
+CONFIG_PHYSICAL_START=0x2000000
 

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
