All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, Paul Mackerras <paulus@samba.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 --]

  parent reply	other threads:[~2008-07-07 23:36 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07  8:40 linux-next: kbuild tree build failure Stephen Rothwell
2008-07-07  8:40 ` Stephen Rothwell
2008-07-07 12:51 ` Sam Ravnborg
2008-07-07 12:51   ` Sam Ravnborg
2008-07-07 13:08   ` Stephen Rothwell
2008-07-07 13:08     ` Stephen Rothwell
2008-07-07 16:13 ` Roman Zippel
2008-07-07 16:13   ` Roman Zippel
2008-07-07 21:01   ` Sam Ravnborg
2008-07-07 23:36   ` Michael Ellerman [this message]
2008-07-07 23:36     ` Michael Ellerman
2008-07-08  2:55     ` Roman Zippel
2008-07-08  2:55       ` Roman Zippel
2008-07-10  0:51       ` Michael Ellerman
2008-07-10  0:51         ` Michael Ellerman
2008-07-10 14:59         ` Roman Zippel
2008-07-10 14:59           ` Roman Zippel
2008-07-14 16:53           ` Milton Miller
2008-07-14 16:53             ` Milton Miller
2008-07-08 21:19   ` Sam Ravnborg
2008-07-10 14:52     ` Roman Zippel
2008-07-25  4:13 ` Stephen Rothwell
2008-07-25  4:13   ` Stephen Rothwell
2008-07-26 10:06   ` Sam Ravnborg
2008-07-26 10:06     ` Sam Ravnborg
2008-07-26 12:40     ` Stephen Rothwell
2008-07-26 12:40       ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2008-07-12 22:32 Milton Miller
2008-07-12 22:32 ` Milton Miller
2008-07-12 23:21 ` Roman Zippel
2008-07-12 23:21   ` Roman Zippel
2008-11-25  4:47 Stephen Rothwell
2008-11-25  8:42 ` Sam Ravnborg
2008-11-25  8:58   ` Stephen Rothwell
2008-11-26  4:42 Stephen Rothwell
2008-11-26 21:06 ` Sam Ravnborg
2008-11-26 23:49   ` Stephen Rothwell
2008-12-03  0:36   ` Stephen Rothwell
2008-12-03  9:46     ` Sam Ravnborg
2009-05-05  1:17 Stephen Rothwell
2009-05-05  6:35 ` Jan Beulich
2009-05-05  6:43   ` Sam Ravnborg
2009-05-05  7:04     ` Jan Beulich
2009-06-09  1:48 Stephen Rothwell
2009-06-09 16:15 ` Sam Ravnborg
2009-06-09 16:19   ` Stephen Rothwell
2009-06-09 21:04     ` Sam Ravnborg
2009-06-09 23:27       ` Stephen Rothwell
2009-10-14  1:20 Stephen Rothwell
2009-10-14  7:43 ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1215473798.8138.4.camel@localhost \
    --to=michael@ellerman.id.au \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=sam@ravnborg.org \
    --cc=sfr@canb.auug.org.au \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.