* linux-next: kbuild tree build failure
@ 2008-07-07 8:40 Stephen Rothwell
2008-07-07 12:51 ` Sam Ravnborg
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Stephen Rothwell @ 2008-07-07 8:40 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
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
This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID
(line 194).
>From include/asm-powerpc/pgtable-ppc64.h:
#define REGION_SHIFT 60UL
#define REGION_MASK (0xfUL << REGION_SHIFT)
#define REGION_ID(ea) (((unsigned long)(ea)) >> REGION_SHIFT)
#define VMALLOC_REGION_ID (REGION_ID(VMALLOC_START))
#define KERNEL_REGION_ID (REGION_ID(PAGE_OFFSET))
#define VMEMMAP_REGION_ID (0xfUL)
#define USER_REGION_ID (0UL)
>From include/asm-powerpc/page.h:
#define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET)
>From .config:
CONFIG_PAGE_OFFSET=0xffffffff
Not good.
>From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set):
config PAGE_OFFSET_BOOL
bool "Set custom page offset address"
depends on ADVANCED_OPTIONS
config PAGE_OFFSET
hex "Virtual address of memory base" if PAGE_OFFSET_BOOL
default "0xc0000000"
if PPC64
config PAGE_OFFSET
hex
default "0xc000000000000000"
endif
Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig:
normalize int/hex values") seems to have fixed it.
>From .config:
CONFIG_PAGE_OFFSET=0xc000000000000000
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: linux-next: kbuild tree build failure 2008-07-07 8:40 linux-next: kbuild tree build failure Stephen Rothwell @ 2008-07-07 12:51 ` Sam Ravnborg 2008-07-07 13:08 ` Stephen Rothwell 2008-07-07 16:13 ` Roman Zippel 2008-07-25 4:13 ` Stephen Rothwell 2 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2008-07-07 12:51 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev On Mon, Jul 07, 2008 at 06:40:38PM +1000, 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 > > This means that USER_REGION_ID (line 177) is the same as KERNEL_REGION_ID > (line 194). > > From include/asm-powerpc/pgtable-ppc64.h: > > #define REGION_SHIFT 60UL > #define REGION_MASK (0xfUL << REGION_SHIFT) > #define REGION_ID(ea) (((unsigned long)(ea)) >> REGION_SHIFT) > > #define VMALLOC_REGION_ID (REGION_ID(VMALLOC_START)) > #define KERNEL_REGION_ID (REGION_ID(PAGE_OFFSET)) > #define VMEMMAP_REGION_ID (0xfUL) > #define USER_REGION_ID (0UL) > > From include/asm-powerpc/page.h: > > #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET) > > From .config: > > CONFIG_PAGE_OFFSET=0xffffffff > > Not good. > > From arch/powerpc/Kconfig (ADVANCED_OPTIONS is not set): > > config PAGE_OFFSET_BOOL > bool "Set custom page offset address" > depends on ADVANCED_OPTIONS > > config PAGE_OFFSET > hex "Virtual address of memory base" if PAGE_OFFSET_BOOL > default "0xc0000000" > > if PPC64 > config PAGE_OFFSET > hex > default "0xc000000000000000" > endif > > Reverting commit 9ba4ff5059e1a26698786373c8c71321c37ef7f9 ("kconfig: > normalize int/hex values") seems to have fixed it. > > From .config: > > CONFIG_PAGE_OFFSET=0xc000000000000000 I see what is wrong - we use a int to hold the value above and it does not fit. Will fix tonight or tomorrow. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 12:51 ` Sam Ravnborg @ 2008-07-07 13:08 ` Stephen Rothwell 0 siblings, 0 replies; 33+ messages in thread From: Stephen Rothwell @ 2008-07-07 13:08 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 331 bytes --] Hi Sam, On Mon, 7 Jul 2008 14:51:38 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > I see what is wrong - we use a int to hold the value above > and it does not fit. > > Will fix tonight or tomorrow. Thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 8:40 linux-next: kbuild tree build failure Stephen Rothwell 2008-07-07 12:51 ` Sam Ravnborg @ 2008-07-07 16:13 ` Roman Zippel 2008-07-07 21:01 ` Sam Ravnborg ` (2 more replies) 2008-07-25 4:13 ` Stephen Rothwell 2 siblings, 3 replies; 33+ messages in thread From: Roman Zippel @ 2008-07-07 16:13 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Sam Ravnborg, linux-next, Paul Mackerras, linuxppc-dev 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). Below is a patch that fixes this for all archs (generated against the git tree). The powerpc parts need a more careful review, the rest isn't really critical. bye, Roman Fix remaining warnings generated kconfig to normalize all constant values. Generate powerpc 64bit page offset via header instead of kconfig. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> --- arch/arm/Kconfig | 4 ++-- arch/arm/Kconfig-nommu | 10 +++++----- arch/arm/mm/Kconfig | 4 ++-- arch/blackfin/Kconfig | 12 ++++++------ arch/blackfin/mach-bf548/Kconfig | 8 ++++---- arch/cris/arch-v10/Kconfig | 26 +++++++++++++------------- arch/cris/arch-v10/drivers/Kconfig | 14 +++++++------- arch/cris/arch-v32/Kconfig | 28 ++++++++++++++-------------- arch/cris/arch-v32/drivers/Kconfig | 30 ++++++++++++------------------ arch/cris/arch-v32/mach-a3/Kconfig | 14 +++++++------- arch/cris/arch-v32/mach-fs/Kconfig | 32 ++++++++++++++++---------------- arch/frv/Kconfig | 4 ++-- arch/m32r/Kconfig | 36 ++++++++++++++++++------------------ arch/powerpc/Kconfig | 16 ++++++---------- arch/ppc/Kconfig | 8 ++++---- arch/sh/Kconfig | 10 +++++----- arch/sh/Kconfig.debug | 2 +- arch/sh/mm/Kconfig | 6 +++--- include/asm-powerpc/page.h | 10 ++++++++-- 19 files changed, 135 insertions(+), 139 deletions(-) Index: linux-2.6/arch/arm/Kconfig =================================================================== --- linux-2.6.orig/arch/arm/Kconfig +++ linux-2.6/arch/arm/Kconfig @@ -168,7 +168,7 @@ config VECTORS_BASE hex default 0xffff0000 if MMU || CPU_HIGH_VECTOR default DRAM_BASE if REMAP_VECTORS_TO_RAM - default 0x00000000 + default 0 help The base address of exception vectors. @@ -924,7 +924,7 @@ config XIP_KERNEL config XIP_PHYS_ADDR hex "XIP Kernel Physical Location" depends on XIP_KERNEL - default "0x00080000" + default "0x80000" help This is the physical address in your flash memory the kernel will be linked for and stored to. This address is dependent on your Index: linux-2.6/arch/arm/Kconfig-nommu =================================================================== --- linux-2.6.orig/arch/arm/Kconfig-nommu +++ linux-2.6/arch/arm/Kconfig-nommu @@ -11,23 +11,23 @@ config SET_MEM_PARAM config DRAM_BASE hex '(S)DRAM Base Address' if SET_MEM_PARAM - default 0x00800000 + default 0x800000 config DRAM_SIZE hex '(S)DRAM SIZE' if SET_MEM_PARAM - default 0x00800000 + default 0x800000 config FLASH_MEM_BASE hex 'FLASH Base Address' if SET_MEM_PARAM - default 0x00400000 + default 0x400000 config FLASH_SIZE hex 'FLASH Size' if SET_MEM_PARAM - default 0x00400000 + default 0x400000 config PROCESSOR_ID hex 'Hard wire the processor ID' - default 0x00007700 + default 0x7700 depends on !CPU_CP15 help If processor has no CP15 register, this processor ID is Index: linux-2.6/arch/arm/mm/Kconfig =================================================================== --- linux-2.6.orig/arch/arm/mm/Kconfig +++ linux-2.6/arch/arm/mm/Kconfig @@ -649,8 +649,8 @@ config CPU_DCACHE_DISABLE config CPU_DCACHE_SIZE hex depends on CPU_ARM740T || CPU_ARM946E - default 0x00001000 if CPU_ARM740T - default 0x00002000 # default size for ARM946E-S + default 0x1000 if CPU_ARM740T + default 0x2000 # default size for ARM946E-S help Some cores are synthesizable to have various sized cache. For ARM946E-S case, it can vary from 0KB to 1MB. Index: linux-2.6/arch/blackfin/Kconfig =================================================================== --- linux-2.6.orig/arch/blackfin/Kconfig +++ linux-2.6/arch/blackfin/Kconfig @@ -819,20 +819,20 @@ endmenu menu "EBIU_AMBCTL Control" config BANK_0 hex "Bank 0" - default 0x7BB0 + default 0x7bb0 config BANK_1 hex "Bank 1" - default 0x7BB0 + default 0x7bb0 default 0x5558 if BF54x config BANK_2 hex "Bank 2" - default 0x7BB0 + default 0x7bb0 config BANK_3 hex "Bank 3" - default 0x99B3 + default 0x99b3 endmenu config EBIU_MBSCTLVAL @@ -843,12 +843,12 @@ config EBIU_MBSCTLVAL config EBIU_MODEVAL hex "Flash Memory Mode Control Register" depends on BF54x - default 1 + default 0x1 config EBIU_FCTLVAL hex "Flash Memory Bank Control Register" depends on BF54x - default 6 + default 0x6 endmenu ############################################################################# Index: linux-2.6/arch/blackfin/mach-bf548/Kconfig =================================================================== --- linux-2.6.orig/arch/blackfin/mach-bf548/Kconfig +++ linux-2.6/arch/blackfin/mach-bf548/Kconfig @@ -304,19 +304,19 @@ config PINTx_REASSIGN config PINT0_ASSIGN hex "PINT0_ASSIGN" depends on PINTx_REASSIGN - default 0x00000101 + default 0x101 config PINT1_ASSIGN hex "PINT1_ASSIGN" depends on PINTx_REASSIGN - default 0x01010000 + default 0x1010000 config PINT2_ASSIGN hex "PINT2_ASSIGN" depends on PINTx_REASSIGN - default 0x07000101 + default 0x7000101 config PINT3_ASSIGN hex "PINT3_ASSIGN" depends on PINTx_REASSIGN - default 0x02020303 + default 0x2020303 endmenu Index: linux-2.6/arch/cris/arch-v10/Kconfig =================================================================== --- linux-2.6.orig/arch/cris/arch-v10/Kconfig +++ linux-2.6/arch/cris/arch-v10/Kconfig @@ -11,8 +11,8 @@ config CRIS_LOW_MAP config ETRAX_DRAM_VIRTUAL_BASE hex depends on ETRAX_ARCH_V10 - default "c0000000" if !ETRAX100LX - default "60000000" if ETRAX100LX + default "0xc0000000" if !ETRAX100LX + default "0x60000000" if ETRAX100LX choice prompt "Product LED port" @@ -262,7 +262,7 @@ endchoice config ETRAX_DEF_R_WAITSTATES hex "R_WAITSTATES" depends on ETRAX_ARCH_V10 - default "95a6" + default "0x95a6" help Waitstates for SRAM, Flash and peripherals (not DRAM). 95f8 is a good choice for most Axis products... @@ -270,7 +270,7 @@ config ETRAX_DEF_R_WAITSTATES config ETRAX_DEF_R_BUS_CONFIG hex "R_BUS_CONFIG" depends on ETRAX_ARCH_V10 - default "104" + default "0x104" help Assorted bits controlling write mode, DMA burst length etc. 104 is a good choice for most Axis products... @@ -285,7 +285,7 @@ config ETRAX_SDRAM config ETRAX_DEF_R_DRAM_CONFIG hex "R_DRAM_CONFIG" depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM - default "1a200040" + default "0x1a200040" help The R_DRAM_CONFIG register specifies everything on how the DRAM chips in the system are connected to the ETRAX CPU. This is @@ -296,7 +296,7 @@ config ETRAX_DEF_R_DRAM_CONFIG config ETRAX_DEF_R_DRAM_TIMING hex "R_DRAM_TIMING" depends on ETRAX_ARCH_V10 && !ETRAX_SDRAM - default "5611" + default "0x5611" help Different DRAM chips have different speeds. Current Axis products use 50ns DRAM chips which can use the timing: 5611. @@ -304,7 +304,7 @@ config ETRAX_DEF_R_DRAM_TIMING config ETRAX_DEF_R_SDRAM_CONFIG hex "R_SDRAM_CONFIG" depends on ETRAX_ARCH_V10 && ETRAX_SDRAM - default "d2fa7878" + default "0xd2fa7878" help The R_SDRAM_CONFIG register specifies everything on how the SDRAM chips in the system are connected to the ETRAX CPU. This is @@ -315,14 +315,14 @@ config ETRAX_DEF_R_SDRAM_CONFIG config ETRAX_DEF_R_SDRAM_TIMING hex "R_SDRAM_TIMING" depends on ETRAX_ARCH_V10 && ETRAX_SDRAM - default "80004801" + default "0x80004801" help Different SDRAM chips have different timing. config ETRAX_DEF_R_PORT_PA_DIR hex "R_PORT_PA_DIR" depends on ETRAX_ARCH_V10 - default "1c" + default "0x1c" help Configures the direction of general port A bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -336,7 +336,7 @@ config ETRAX_DEF_R_PORT_PA_DIR config ETRAX_DEF_R_PORT_PA_DATA hex "R_PORT_PA_DATA" depends on ETRAX_ARCH_V10 - default "00" + default "0" help Configures the initial data for the general port A bits. Most products should use 00 here. @@ -344,7 +344,7 @@ config ETRAX_DEF_R_PORT_PA_DATA config ETRAX_DEF_R_PORT_PB_CONFIG hex "R_PORT_PB_CONFIG" depends on ETRAX_ARCH_V10 - default "00" + default "0" help Configures the type of the general port B bits. 1 is chip select, 0 is port. Most products should use 00 here. @@ -352,7 +352,7 @@ config ETRAX_DEF_R_PORT_PB_CONFIG config ETRAX_DEF_R_PORT_PB_DIR hex "R_PORT_PB_DIR" depends on ETRAX_ARCH_V10 - default "00" + default "0" help Configures the direction of general port B bits. 1 is out, 0 is in. This is often totally different depending on the product used. Bits @@ -365,7 +365,7 @@ config ETRAX_DEF_R_PORT_PB_DIR config ETRAX_DEF_R_PORT_PB_DATA hex "R_PORT_PB_DATA" depends on ETRAX_ARCH_V10 - default "ff" + default "0xff" help Configures the initial data for the general port A bits. Most products should use FF here. Index: linux-2.6/arch/cris/arch-v10/drivers/Kconfig =================================================================== --- linux-2.6.orig/arch/cris/arch-v10/drivers/Kconfig +++ linux-2.6/arch/cris/arch-v10/drivers/Kconfig @@ -531,20 +531,20 @@ config ETRAX_GPIO config ETRAX_PA_BUTTON_BITMASK hex "PA-buttons bitmask" depends on ETRAX_GPIO - default "02" + default "0x2" help This is a bitmask with information about what bits on PA that are used for buttons. Most products has a so called TEST button on PA1, if that's true - use 02 here. - Use 00 if there are no buttons on PA. + use 0x2 here. + Use 0x0 if there are no buttons on PA. If the bitmask is <> 00 a button driver will be included in the gpio driver. ETRAX general I/O support must be enabled. config ETRAX_PA_CHANGEABLE_DIR hex "PA user changeable dir mask" depends on ETRAX_GPIO - default "00" + default "0" help This is a bitmask with information of what bits in PA that a user can change direction on using ioctl's. @@ -554,7 +554,7 @@ config ETRAX_PA_CHANGEABLE_DIR config ETRAX_PA_CHANGEABLE_BITS hex "PA user changeable bits mask" depends on ETRAX_GPIO - default "FF" + default "0xff" help This is a bitmask with information of what bits in PA that a user can change the value on using ioctl's. @@ -564,7 +564,7 @@ config ETRAX_PA_CHANGEABLE_BITS config ETRAX_PB_CHANGEABLE_DIR hex "PB user changeable dir mask" depends on ETRAX_GPIO - default "00" + default "0" help This is a bitmask with information of what bits in PB that a user can change direction on using ioctl's. @@ -574,7 +574,7 @@ config ETRAX_PB_CHANGEABLE_DIR config ETRAX_PB_CHANGEABLE_BITS hex "PB user changeable bits mask" depends on ETRAX_GPIO - default "FF" + default "0xff" help This is a bitmask with information of what bits in PB that a user can change the value on using ioctl's. Index: linux-2.6/arch/cris/arch-v32/Kconfig =================================================================== --- linux-2.6.orig/arch/cris/arch-v32/Kconfig +++ linux-2.6/arch/cris/arch-v32/Kconfig @@ -8,7 +8,7 @@ source drivers/cpufreq/Kconfig config ETRAX_DRAM_VIRTUAL_BASE hex depends on ETRAX_ARCH_V32 - default "c0000000" + default "0xc0000000" choice prompt "Nbr of Ethernet LED groups" @@ -119,7 +119,7 @@ endchoice config ETRAX_MEM_GRP1_CONFIG hex "MEM_GRP1_CONFIG" depends on ETRAX_ARCH_V32 - default "4044a" + default "0x4044a" help Waitstates for flash. The default value is suitable for the standard flashes used in axis products (120 ns). @@ -150,7 +150,7 @@ config ETRAX_MEM_GRP4_CONFIG config ETRAX_SDRAM_GRP0_CONFIG hex "SDRAM_GRP0_CONFIG" depends on ETRAX_ARCH_V32 - default "336" + default "0x336" help SDRAM configuration for group 0. The value depends on the hardware configuration. The default value is suitable @@ -170,7 +170,7 @@ config ETRAX_SDRAM_GRP1_CONFIG config ETRAX_SDRAM_TIMING hex "SDRAM_TIMING" depends on ETRAX_ARCH_V32 - default "104a" + default "0x104a" help SDRAM timing parameters. The default value is ok for most hardwares but large SDRAMs may require a faster @@ -189,7 +189,7 @@ config ETRAX_SDRAM_COMMAND config ETRAX_DEF_GIO_PA_OE hex "GIO_PA_OE" depends on ETRAX_ARCH_V32 - default "1c" + default "0x1c" help Configures the direction of general port A bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -203,7 +203,7 @@ config ETRAX_DEF_GIO_PA_OE config ETRAX_DEF_GIO_PA_OUT hex "GIO_PA_OUT" depends on ETRAX_ARCH_V32 - default "00" + default "0" help Configures the initial data for the general port A bits. Most products should use 00 here. @@ -211,7 +211,7 @@ config ETRAX_DEF_GIO_PA_OUT config ETRAX_DEF_GIO_PB_OE hex "GIO_PB_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port B bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -225,7 +225,7 @@ config ETRAX_DEF_GIO_PB_OE config ETRAX_DEF_GIO_PB_OUT hex "GIO_PB_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port B bits. Most products should use 00000 here. @@ -233,7 +233,7 @@ config ETRAX_DEF_GIO_PB_OUT config ETRAX_DEF_GIO_PC_OE hex "GIO_PC_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port C bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -247,7 +247,7 @@ config ETRAX_DEF_GIO_PC_OE config ETRAX_DEF_GIO_PC_OUT hex "GIO_PC_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port C bits. Most products should use 00000 here. @@ -255,7 +255,7 @@ config ETRAX_DEF_GIO_PC_OUT config ETRAX_DEF_GIO_PD_OE hex "GIO_PD_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port D bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -269,7 +269,7 @@ config ETRAX_DEF_GIO_PD_OE config ETRAX_DEF_GIO_PD_OUT hex "GIO_PD_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port D bits. Most products should use 00000 here. @@ -277,7 +277,7 @@ config ETRAX_DEF_GIO_PD_OUT config ETRAX_DEF_GIO_PE_OE hex "GIO_PE_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port E bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -291,7 +291,7 @@ config ETRAX_DEF_GIO_PE_OE config ETRAX_DEF_GIO_PE_OUT hex "GIO_PE_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port E bits. Most products should use 00000 here. Index: linux-2.6/arch/cris/arch-v32/drivers/Kconfig =================================================================== --- linux-2.6.orig/arch/cris/arch-v32/drivers/Kconfig +++ linux-2.6/arch/cris/arch-v32/drivers/Kconfig @@ -513,8 +513,7 @@ config ETRAX_VIRTUAL_GPIO_INTERRUPT_PA_P config ETRAX_PA_CHANGEABLE_DIR hex "PA user changeable dir mask" depends on ETRAX_GPIO - default "0x00" if ETRAXFS - default "0x00000000" if !ETRAXFS + default "0" help This is a bitmask (8 bits) with information of what bits in PA that a user can change direction on using ioctl's. @@ -524,8 +523,7 @@ config ETRAX_PA_CHANGEABLE_DIR config ETRAX_PA_CHANGEABLE_BITS hex "PA user changeable bits mask" depends on ETRAX_GPIO - default "0x00" if ETRAXFS - default "0x00000000" if !ETRAXFS + default "0" help This is a bitmask (8 bits) with information of what bits in PA that a user can change the value on using ioctl's. @@ -534,8 +532,7 @@ config ETRAX_PA_CHANGEABLE_BITS config ETRAX_PB_CHANGEABLE_DIR hex "PB user changeable dir mask" depends on ETRAX_GPIO - default "0x00000" if ETRAXFS - default "0x00000000" if !ETRAXFS + default "0" help This is a bitmask (18 bits) with information of what bits in PB that a user can change direction on using ioctl's. @@ -545,8 +542,7 @@ config ETRAX_PB_CHANGEABLE_DIR config ETRAX_PB_CHANGEABLE_BITS hex "PB user changeable bits mask" depends on ETRAX_GPIO - default "0x00000" if ETRAXFS - default "0x00000000" if !ETRAXFS + default "0" help This is a bitmask (18 bits) with information of what bits in PB that a user can change the value on using ioctl's. @@ -555,8 +551,7 @@ config ETRAX_PB_CHANGEABLE_BITS config ETRAX_PC_CHANGEABLE_DIR hex "PC user changeable dir mask" depends on ETRAX_GPIO - default "0x00000" if ETRAXFS - default "0x00000000" if !ETRAXFS + default "0" help This is a bitmask (18 bits) with information of what bits in PC that a user can change direction on using ioctl's. @@ -566,8 +561,7 @@ config ETRAX_PC_CHANGEABLE_DIR config ETRAX_PC_CHANGEABLE_BITS hex "PC user changeable bits mask" depends on ETRAX_GPIO - default "0x00000" if ETRAXFS - default "0x00000000" if ETRAXFS + default "0" help This is a bitmask (18 bits) with information of what bits in PC that a user can change the value on using ioctl's. @@ -576,7 +570,7 @@ config ETRAX_PC_CHANGEABLE_BITS config ETRAX_PD_CHANGEABLE_DIR hex "PD user changeable dir mask" depends on ETRAX_GPIO && ETRAXFS - default "0x00000" + default "0" help This is a bitmask (18 bits) with information of what bits in PD that a user can change direction on using ioctl's. @@ -586,7 +580,7 @@ config ETRAX_PD_CHANGEABLE_DIR config ETRAX_PD_CHANGEABLE_BITS hex "PD user changeable bits mask" depends on ETRAX_GPIO && ETRAXFS - default "0x00000" + default "0" help This is a bitmask (18 bits) with information of what bits in PD that a user can change the value on using ioctl's. @@ -595,7 +589,7 @@ config ETRAX_PD_CHANGEABLE_BITS config ETRAX_PE_CHANGEABLE_DIR hex "PE user changeable dir mask" depends on ETRAX_GPIO && ETRAXFS - default "0x00000" + default "0" help This is a bitmask (18 bits) with information of what bits in PE that a user can change direction on using ioctl's. @@ -605,7 +599,7 @@ config ETRAX_PE_CHANGEABLE_DIR config ETRAX_PE_CHANGEABLE_BITS hex "PE user changeable bits mask" depends on ETRAX_GPIO && ETRAXFS - default "0x00000" + default "0" help This is a bitmask (18 bits) with information of what bits in PE that a user can change the value on using ioctl's. @@ -614,7 +608,7 @@ config ETRAX_PE_CHANGEABLE_BITS config ETRAX_PV_CHANGEABLE_DIR hex "PV user changeable dir mask" depends on ETRAX_VIRTUAL_GPIO - default "0x0000" + default "0" help This is a bitmask (16 bits) with information of what bits in PV that a user can change direction on using ioctl's. @@ -624,7 +618,7 @@ config ETRAX_PV_CHANGEABLE_DIR config ETRAX_PV_CHANGEABLE_BITS hex "PV user changeable bits mask" depends on ETRAX_VIRTUAL_GPIO - default "0x0000" + default "0" help This is a bitmask (16 bits) with information of what bits in PV that a user can change the value on using ioctl's. Index: linux-2.6/arch/cris/arch-v32/mach-a3/Kconfig =================================================================== --- linux-2.6.orig/arch/cris/arch-v32/mach-a3/Kconfig +++ linux-2.6/arch/cris/arch-v32/mach-a3/Kconfig @@ -5,7 +5,7 @@ menu "Artpec-3 options" config ETRAX_DRAM_VIRTUAL_BASE hex - default "c0000000" + default "0xc0000000" config ETRAX_L2CACHE bool @@ -47,7 +47,7 @@ config ETRAX_PIO_CE2_CFG config ETRAX_DEF_GIO_PA_OE hex "GIO_PA_OE" - default "00000000" + default "0" help Configures the direction of general port A bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -60,14 +60,14 @@ config ETRAX_DEF_GIO_PA_OE config ETRAX_DEF_GIO_PA_OUT hex "GIO_PA_OUT" - default "00000000" + default "0" help Configures the initial data for the general port A bits. Most products should use 00 here. config ETRAX_DEF_GIO_PB_OE hex "GIO_PB_OE" - default "000000000" + default "0" help Configures the direction of general port B bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -80,14 +80,14 @@ config ETRAX_DEF_GIO_PB_OE config ETRAX_DEF_GIO_PB_OUT hex "GIO_PB_OUT" - default "000000000" + default "0" help Configures the initial data for the general port B bits. Most products should use 00000 here. config ETRAX_DEF_GIO_PC_OE hex "GIO_PC_OE" - default "00000" + default "0" help Configures the direction of general port C bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -100,7 +100,7 @@ config ETRAX_DEF_GIO_PC_OE config ETRAX_DEF_GIO_PC_OUT hex "GIO_PC_OUT" - default "00000" + default "0" help Configures the initial data for the general port C bits. Most products should use 00000 here. Index: linux-2.6/arch/cris/arch-v32/mach-fs/Kconfig =================================================================== --- linux-2.6.orig/arch/cris/arch-v32/mach-fs/Kconfig +++ linux-2.6/arch/cris/arch-v32/mach-fs/Kconfig @@ -6,7 +6,7 @@ menu "ETRAX FS options" config ETRAX_DRAM_VIRTUAL_BASE hex depends on ETRAX_ARCH_V32 - default "c0000000" + default "0xc0000000" config ETRAX_SERIAL_PORTS int @@ -15,7 +15,7 @@ config ETRAX_SERIAL_PORTS config ETRAX_MEM_GRP1_CONFIG hex "MEM_GRP1_CONFIG" depends on ETRAX_ARCH_V32 - default "4044a" + default "0x4044a" help Waitstates for flash. The default value is suitable for the standard flashes used in axis products (120 ns). @@ -46,7 +46,7 @@ config ETRAX_MEM_GRP4_CONFIG config ETRAX_SDRAM_GRP0_CONFIG hex "SDRAM_GRP0_CONFIG" depends on ETRAX_ARCH_V32 - default "336" + default "0x336" help SDRAM configuration for group 0. The value depends on the hardware configuration. The default value is suitable @@ -66,7 +66,7 @@ config ETRAX_SDRAM_GRP1_CONFIG config ETRAX_SDRAM_TIMING hex "SDRAM_TIMING" depends on ETRAX_ARCH_V32 - default "104a" + default "0x104a" help SDRAM timing parameters. The default value is ok for most hardwares but large SDRAMs may require a faster @@ -85,7 +85,7 @@ config ETRAX_SDRAM_COMMAND config ETRAX_DEF_GIO_PA_OE hex "GIO_PA_OE" depends on ETRAX_ARCH_V32 - default "1c" + default "0x1c" help Configures the direction of general port A bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -99,7 +99,7 @@ config ETRAX_DEF_GIO_PA_OE config ETRAX_DEF_GIO_PA_OUT hex "GIO_PA_OUT" depends on ETRAX_ARCH_V32 - default "00" + default "0" help Configures the initial data for the general port A bits. Most products should use 00 here. @@ -107,7 +107,7 @@ config ETRAX_DEF_GIO_PA_OUT config ETRAX_DEF_GIO_PB_OE hex "GIO_PB_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port B bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -121,7 +121,7 @@ config ETRAX_DEF_GIO_PB_OE config ETRAX_DEF_GIO_PB_OUT hex "GIO_PB_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port B bits. Most products should use 00000 here. @@ -129,7 +129,7 @@ config ETRAX_DEF_GIO_PB_OUT config ETRAX_DEF_GIO_PC_OE hex "GIO_PC_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port C bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -143,7 +143,7 @@ config ETRAX_DEF_GIO_PC_OE config ETRAX_DEF_GIO_PC_OUT hex "GIO_PC_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port C bits. Most products should use 00000 here. @@ -151,7 +151,7 @@ config ETRAX_DEF_GIO_PC_OUT config ETRAX_DEF_GIO_PD_OE hex "GIO_PD_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port D bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -165,7 +165,7 @@ config ETRAX_DEF_GIO_PD_OE config ETRAX_DEF_GIO_PD_OUT hex "GIO_PD_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port D bits. Most products should use 00000 here. @@ -173,7 +173,7 @@ config ETRAX_DEF_GIO_PD_OUT config ETRAX_DEF_GIO_PE_OE hex "GIO_PE_OE" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the direction of general port E bits. 1 is out, 0 is in. This is often totally different depending on the product used. @@ -187,7 +187,7 @@ config ETRAX_DEF_GIO_PE_OE config ETRAX_DEF_GIO_PE_OUT hex "GIO_PE_OUT" depends on ETRAX_ARCH_V32 - default "00000" + default "0" help Configures the initial data for the general port E bits. Most products should use 00000 here. @@ -195,7 +195,7 @@ config ETRAX_DEF_GIO_PE_OUT config ETRAX_DEF_GIO_PV_OE hex "GIO_PV_OE" depends on ETRAX_VIRTUAL_GPIO - default "0000" + default "0" help Configures the direction of virtual general port V bits. 1 is out, 0 is in. This is often totally different depending on the product @@ -206,7 +206,7 @@ config ETRAX_DEF_GIO_PV_OE config ETRAX_DEF_GIO_PV_OUT hex "GIO_PV_OUT" depends on ETRAX_VIRTUAL_GPIO - default "0000" + default "0" help Configures the initial data for the virtual general port V bits. Most products should use 0000 here. Index: linux-2.6/arch/frv/Kconfig =================================================================== --- linux-2.6.orig/arch/frv/Kconfig +++ linux-2.6/arch/frv/Kconfig @@ -149,8 +149,8 @@ config PAGE_OFFSET default 0x40000000 if UCPAGE_OFFSET_40000000 default 0x60000000 if UCPAGE_OFFSET_60000000 default 0x80000000 if UCPAGE_OFFSET_80000000 - default 0xA0000000 if UCPAGE_OFFSET_A0000000 - default 0xC0000000 + default 0xa0000000 if UCPAGE_OFFSET_A0000000 + default 0xc0000000 config PROTECT_KERNEL bool "Protect core kernel against userspace" Index: linux-2.6/arch/m32r/Kconfig =================================================================== --- linux-2.6.orig/arch/m32r/Kconfig +++ linux-2.6/arch/m32r/Kconfig @@ -199,22 +199,22 @@ config CPU_LITTLE_ENDIAN config MEMORY_START hex "Physical memory start address (hex)" - default "08000000" if PLAT_MAPPI || PLAT_MAPPI2 || PLAT_MAPPI3 - default "08000000" if PLAT_USRV - default "08000000" if PLAT_M32700UT - default "08000000" if PLAT_OPSPUT - default "04000000" if PLAT_M32104UT - default "01000000" if PLAT_OAKS32R + default "0x8000000" if PLAT_MAPPI || PLAT_MAPPI2 || PLAT_MAPPI3 + default "0x8000000" if PLAT_USRV + default "0x8000000" if PLAT_M32700UT + default "0x8000000" if PLAT_OPSPUT + default "0x4000000" if PLAT_M32104UT + default "0x1000000" if PLAT_OAKS32R config MEMORY_SIZE hex "Physical memory size (hex)" - default "08000000" if PLAT_MAPPI3 - default "04000000" if PLAT_MAPPI || PLAT_MAPPI2 - default "02000000" if PLAT_USRV - default "01000000" if PLAT_M32700UT - default "01000000" if PLAT_OPSPUT - default "01000000" if PLAT_M32104UT - default "00800000" if PLAT_OAKS32R + default "0x8000000" if PLAT_MAPPI3 + default "0x4000000" if PLAT_MAPPI || PLAT_MAPPI2 + default "0x2000000" if PLAT_USRV + default "0x1000000" if PLAT_M32700UT + default "0x1000000" if PLAT_OPSPUT + default "0x1000000" if PLAT_M32104UT + default "0x800000" if PLAT_OAKS32R config NOHIGHMEM bool @@ -229,16 +229,16 @@ source "mm/Kconfig" config IRAM_START hex "Internal memory start address (hex)" - default "00f00000" if !CHIP_M32104 - default "00700000" if CHIP_M32104 + default "0xf00000" if !CHIP_M32104 + default "0x700000" if CHIP_M32104 depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM config IRAM_SIZE hex "Internal memory size (hex)" depends on (CHIP_M32700 || CHIP_M32102 || CHIP_VDEC2 || CHIP_OPSP || CHIP_M32104) && DISCONTIGMEM - default "00080000" if CHIP_M32700 - default "00010000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104 - default "00008000" if CHIP_VDEC2 + default "0x80000" if CHIP_M32700 + default "0x10000" if CHIP_M32102 || CHIP_OPSP || CHIP_M32104 + default "0x8000" if CHIP_VDEC2 # # Define implied options from the CPU selection here 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" config PHYSICAL_START hex - default "0x02000000" if CRASH_DUMP - default "0x00000000" + default "0x2000000" if CRASH_DUMP + default "0" endif source "net/Kconfig" Index: linux-2.6/arch/ppc/Kconfig =================================================================== --- linux-2.6.orig/arch/ppc/Kconfig +++ linux-2.6/arch/ppc/Kconfig @@ -1120,7 +1120,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 BOOT_LOAD_BOOL bool "Set the boot link/load address" @@ -1134,9 +1134,9 @@ config BOOT_LOAD_BOOL config BOOT_LOAD hex "Link/load address for booting" if BOOT_LOAD_BOOL - default "0x00400000" if 40x || 8xx || 8260 - default "0x01000000" if 44x - default "0x00800000" + default "0x400000" if 40x || 8xx || 8260 + default "0x1000000" if 44x + default "0x800000" config PIN_TLB bool "Pinned Kernel TLBs (860 ONLY)" Index: linux-2.6/arch/sh/Kconfig =================================================================== --- linux-2.6.orig/arch/sh/Kconfig +++ linux-2.6/arch/sh/Kconfig @@ -753,16 +753,16 @@ menu "Boot options" config ZERO_PAGE_OFFSET hex "Zero page offset" - default "0x00004000" if SH_SH03 - default "0x00010000" if PAGE_SIZE_64KB - default "0x00002000" if PAGE_SIZE_8KB - default "0x00001000" + default "0x4000" if SH_SH03 + default "0x10000" if PAGE_SIZE_64KB + default "0x2000" if PAGE_SIZE_8KB + default "0x1000" help This sets the default offset of zero page. config BOOT_LINK_OFFSET hex "Link address offset for booting" - default "0x00800000" + default "0x800000" help This option allows you to set the link address offset of the zImage. This can be useful if you are on a board which has a small amount of Index: linux-2.6/arch/sh/Kconfig.debug =================================================================== --- linux-2.6.orig/arch/sh/Kconfig.debug +++ linux-2.6/arch/sh/Kconfig.debug @@ -41,7 +41,7 @@ config EARLY_SCIF_CONSOLE_PORT default "0xffea0000" if CPU_SUBTYPE_SH7785 default "0xfffe8000" if CPU_SUBTYPE_SH7203 default "0xfffe9800" if CPU_SUBTYPE_SH7206 || CPU_SUBTYPE_SH7263 - default "0x00000000" + default "0" config EARLY_PRINTK bool "Early printk support" Index: linux-2.6/arch/sh/mm/Kconfig =================================================================== --- linux-2.6.orig/arch/sh/mm/Kconfig +++ linux-2.6/arch/sh/mm/Kconfig @@ -19,11 +19,11 @@ config PAGE_OFFSET hex default "0x80000000" if MMU && SUPERH32 default "0x20000000" if MMU && SUPERH64 - default "0x00000000" + default "0" config MEMORY_START hex "Physical memory start address" - default "0x08000000" + default "0x8000000" ---help--- Computers built with Hitachi SuperH processors always map the ROM starting at address zero. But the processor @@ -39,7 +39,7 @@ config MEMORY_START config MEMORY_SIZE hex "Physical memory size" - default "0x04000000" + default "0x4000000" help This sets the default memory size assumed by your SH kernel. It can be overridden as normal by the 'mem=' argument on the kernel command Index: linux-2.6/include/asm-powerpc/page.h =================================================================== --- linux-2.6.orig/include/asm-powerpc/page.h +++ linux-2.6/include/asm-powerpc/page.h @@ -67,9 +67,15 @@ * If you want to test if something's a kernel address, use is_kernel_addr(). */ -#define KERNELBASE ASM_CONST(CONFIG_KERNEL_START) +#ifdef CONFIG_PPC64 +#define PAGE_OFFSET (ASM_CONST(CONFIG_PAGE_OFFSET) << 32) +#define KERNELBASE (PAGE_OFFSET+ASM_CONST(CONFIG_PHYSICAL_START)) +#define LOAD_OFFSET PAGE_OFFSET +#else +#define KERNELBASE ASM_CONST(CONFIG_KERNEL_START) #define PAGE_OFFSET ASM_CONST(CONFIG_PAGE_OFFSET) -#define LOAD_OFFSET ASM_CONST((CONFIG_KERNEL_START-CONFIG_PHYSICAL_START)) +#define LOAD_OFFSET (ASM_CONST(CONFIG_KERNEL_START)-ASM_CONST(CONFIG_PHYSICAL_START)) +#endif #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_FLATMEM) #ifndef __ASSEMBLY__ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 16:13 ` Roman Zippel @ 2008-07-07 21:01 ` Sam Ravnborg 2008-07-07 23:36 ` Michael Ellerman 2008-07-08 21:19 ` Sam Ravnborg 2 siblings, 0 replies; 33+ messages in thread From: Sam Ravnborg @ 2008-07-07 21:01 UTC (permalink / raw) To: Roman Zippel; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev On Mon, Jul 07, 2008 at 06:13:55PM +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). > > Below is a patch that fixes this for all archs (generated against the git > tree). The powerpc parts need a more careful review, the rest isn't really > critical. > > bye, Roman Hi Roman. >From your patch: > config PINT3_ASSIGN > hex "PINT3_ASSIGN" > depends on PINTx_REASSIGN > - default 0x02020303 > + default 0x2020303 But ths change actually decrease readability of the value. Before we had 4x2 hex characters. But now we have 3x2 + 1x1. Does this check really by us enough to warrant this? I am aware that the check is implmented by: + str = strdup_type(def_sym->name, sym->type); + if (strcmp(str, def_sym->name)) { + prop_warn(prop, + "default for config symbol '%s'" + " should be %s", sym->name, str); + prop->expr->left.sym = sym_lookup(str, SYMBOL_CO + } + free(str); break; Could we soften this check a little maybe? At least so we accept leading null's. As for the patch in general I will await an ack from powerpc before applying it. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 16:13 ` Roman Zippel 2008-07-07 21:01 ` Sam Ravnborg @ 2008-07-07 23:36 ` Michael Ellerman 2008-07-08 2:55 ` Roman Zippel 2008-07-08 21:19 ` Sam Ravnborg 2 siblings, 1 reply; 33+ messages in thread From: Michael Ellerman @ 2008-07-07 23:36 UTC (permalink / raw) To: Roman Zippel Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev [-- 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 23:36 ` Michael Ellerman @ 2008-07-08 2:55 ` Roman Zippel 2008-07-10 0:51 ` Michael Ellerman 0 siblings, 1 reply; 33+ messages in thread From: Roman Zippel @ 2008-07-08 2:55 UTC (permalink / raw) To: Michael Ellerman Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev Hi, On Tue, 8 Jul 2008, Michael Ellerman wrote: > 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. Do you really expect users to insert random 64bit addresses without making a mistake? Please make a realistic case, where the user input of a full 64bit value is required (i.e. where it's not easier to just offer the user a few choices). Currently there is simply no need for this, as even powerpc only used them as constants here. > > 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 Why is this worse? These are constants, you're not supposed to change them anyway. The remaining values are generated in page.h and should be the same as before. If that isn't the case and this patch produces a nonworking kernel, I'd like to hear about it. bye, Roman ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-08 2:55 ` Roman Zippel @ 2008-07-10 0:51 ` Michael Ellerman 2008-07-10 14:59 ` Roman Zippel 0 siblings, 1 reply; 33+ messages in thread From: Michael Ellerman @ 2008-07-10 0:51 UTC (permalink / raw) To: Roman Zippel Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1721 bytes --] On Tue, 2008-07-08 at 04:55 +0200, Roman Zippel wrote: > Hi, > > On Tue, 8 Jul 2008, Michael Ellerman wrote: > > > 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. > > Do you really expect users to insert random 64bit addresses without making > a mistake? Well yes :) But I think that's because you're thinking of "end-users" and I'm thinking of "users" like myself - ie. _I_ use Kconfig and I do expect myself to be able to type a 64-bit address. > > --- .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 > > Why is this worse? These are constants, you're not supposed to change them > anyway. > The remaining values are generated in page.h and should be the same as > before. If that isn't the case and this patch produces a nonworking > kernel, I'd like to hear about it. You're right the built kernel is fine. So it's not a bug, but I think it is nicer to have the real values in the .config. 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-10 0:51 ` Michael Ellerman @ 2008-07-10 14:59 ` Roman Zippel 0 siblings, 0 replies; 33+ messages in thread From: Roman Zippel @ 2008-07-10 14:59 UTC (permalink / raw) To: Michael Ellerman Cc: Stephen Rothwell, Paul Mackerras, linux-next, Sam Ravnborg, linuxppc-dev Hi, On Thu, 10 Jul 2008, Michael Ellerman wrote: > Well yes :) But I think that's because you're thinking of > "end-users" and I'm thinking of "users" like myself - ie. _I_ use > Kconfig and I do expect myself to be able to type a 64-bit address. That doesn't really answer my question, why you need this. > > > --- .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 > > > > Why is this worse? These are constants, you're not supposed to change them > > anyway. > > The remaining values are generated in page.h and should be the same as > > before. If that isn't the case and this patch produces a nonworking > > kernel, I'd like to hear about it. > > You're right the built kernel is fine. So it's not a bug, Good, could someone please ack whether the powerpc changes are acceptable? > but I think it is nicer to have the real values in the .config. Why? bye, Roman ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 16:13 ` Roman Zippel 2008-07-07 21:01 ` Sam Ravnborg 2008-07-07 23:36 ` Michael Ellerman @ 2008-07-08 21:19 ` Sam Ravnborg 2008-07-10 14:52 ` Roman Zippel 2 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2008-07-08 21:19 UTC (permalink / raw) To: Roman Zippel; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev Hi Roman. I thought a bit more about this. > 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. We use Kconfig for a mixture of user editable values and fixed configuration values. And I agree that asking the user to input a 64 bit number is not usefull. But keeping support for 64 bit values is what I would consider expected functionality. So removing support for 64 bit is not good IMO. > This would also ease on any portability issues > (kconfig is compiled with the host compiler not the target compiler). We use strtol() in a few places in symbol.c already where we do an implicit conversion to int. Why did this not cause us problems before? Is it because these code paths are only triggered when we deal with ranges? If so we could 'fix' strdup_type() to not use strto{,u}l() so it is 64 bit clean and we are back to old behaviour. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-08 21:19 ` Sam Ravnborg @ 2008-07-10 14:52 ` Roman Zippel 0 siblings, 0 replies; 33+ messages in thread From: Roman Zippel @ 2008-07-10 14:52 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Stephen Rothwell, linux-next, Paul Mackerras, linuxppc-dev Hi, On Tue, 8 Jul 2008, Sam Ravnborg wrote: > We use Kconfig for a mixture of user editable values and fixed > configuration values. > And I agree that asking the user to input a 64 bit number is not usefull. > > But keeping support for 64 bit values is what I would consider > expected functionality. Isn't that a bit of a stretch? That's a rather generic argument, do we really have to keep everything, because someone _might_ want to use it? I'd rather look at how useful it really is to keep that functionality and so far we exactly one user, which doesn't strictly require it. So far it's more a convenience feature rather than a required feature. We don't lose any functionality, it's just shifted from kconfig to the header file. > > This would also ease on any portability issues > > (kconfig is compiled with the host compiler not the target compiler). > > We use strtol() in a few places in symbol.c already where we do an > implicit conversion to int. Why did this not cause us problems before? > > Is it because these code paths are only triggered when we deal with ranges? > If so we could 'fix' strdup_type() to not use strto{,u}l() so it > is 64 bit clean and we are back to old behaviour. Ranges are the primary reason I made it consistent with this. If we really wanted to support 64bit numbers, it would create only more problems. First you have to make sure that on every build host (i.e also non-Linux) strtoll() is available. Then how it should these numbers be represented? On 32bit these may need a 'll' postfix, but the powerpc example already shows, that there are different requirements, so they use ASM_CONST for that. How should this postprecessing be integrated into kconfig? I would seriously prefer to keep things as simple as possible, unless there is a real requirement for it, but so far there isn't any. If we really needed something like this, I'd rather introduce a new expression type, which works more like an unquoted string (e.g. you could define something like (1l<<$PAGE_SHIFT)), where things like ranges wouldn't work, but it also wouldn't have any content restrictions. bye, Roman ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-07 8:40 linux-next: kbuild tree build failure Stephen Rothwell 2008-07-07 12:51 ` Sam Ravnborg 2008-07-07 16:13 ` Roman Zippel @ 2008-07-25 4:13 ` Stephen Rothwell 2008-07-26 10:06 ` Sam Ravnborg 2 siblings, 1 reply; 33+ messages in thread From: Stephen Rothwell @ 2008-07-25 4:13 UTC (permalink / raw) To: Sam Ravnborg Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev, Benjamin Herrenschmidt, Milton Miller, Michael Ellerman [-- Attachment #1: Type: text/plain, Size: 614 bytes --] Hi Sam, On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > 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 This still fails in linux-next today. We need some solution before you send these commits to Linus. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-25 4:13 ` Stephen Rothwell @ 2008-07-26 10:06 ` Sam Ravnborg 2008-07-26 12:40 ` Stephen Rothwell 0 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2008-07-26 10:06 UTC (permalink / raw) To: Stephen Rothwell Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev, Benjamin Herrenschmidt, Milton Miller, Michael Ellerman On Fri, Jul 25, 2008 at 02:13:30PM +1000, Stephen Rothwell wrote: > Hi Sam, > > On Mon, 7 Jul 2008 18:40:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > 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 > > This still fails in linux-next today. We need some solution before you > send these commits to Linus. I removed the offending commits from kbuild-next before I sent the pull request. I will though revisit the issue after -rc1. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-07-26 10:06 ` Sam Ravnborg @ 2008-07-26 12:40 ` Stephen Rothwell 0 siblings, 0 replies; 33+ messages in thread From: Stephen Rothwell @ 2008-07-26 12:40 UTC (permalink / raw) To: Sam Ravnborg Cc: linux-next, Roman Zippel, Paul Mackerras, linuxppc-dev, Benjamin Herrenschmidt, Milton Miller, Michael Ellerman [-- Attachment #1: Type: text/plain, Size: 349 bytes --] Hi Sam, On Sat, 26 Jul 2008 12:06:32 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > I removed the offending commits from kbuild-next before I > sent the pull request. > I will though revisit the issue after -rc1. Thanks again. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* linux-next: kbuild tree build failure @ 2008-11-25 4:47 Stephen Rothwell 2008-11-25 8:42 ` Sam Ravnborg 0 siblings, 1 reply; 33+ messages in thread From: Stephen Rothwell @ 2008-11-25 4:47 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next [-- Attachment #1: Type: text/plain, Size: 440 bytes --] Hi Sam, Today's linux-next build (powerpc ppc64_defconfig) failed like this: WARNING: modpost: Found 11 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory I have dropped the kbuild 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-11-25 4:47 Stephen Rothwell @ 2008-11-25 8:42 ` Sam Ravnborg 2008-11-25 8:58 ` Stephen Rothwell 0 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2008-11-25 8:42 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next On Tue, Nov 25, 2008 at 03:47:05PM +1100, Stephen Rothwell wrote: > Hi Sam, > > Today's linux-next build (powerpc ppc64_defconfig) failed like this: > > WARNING: modpost: Found 11 section mismatch(es). > To see full details build your kernel with: > 'make CONFIG_DEBUG_SECTION_MISMATCH=y' > .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory > > I have dropped the kbuild tree for today. Fixed. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-11-25 8:42 ` Sam Ravnborg @ 2008-11-25 8:58 ` Stephen Rothwell 0 siblings, 0 replies; 33+ messages in thread From: Stephen Rothwell @ 2008-11-25 8:58 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next [-- Attachment #1: Type: text/plain, Size: 652 bytes --] Hi Sam, On Tue, 25 Nov 2008 09:42:26 +0100 Sam Ravnborg <sam@ravnborg.org> wrote: > > On Tue, Nov 25, 2008 at 03:47:05PM +1100, Stephen Rothwell wrote: > > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this: > > > > WARNING: modpost: Found 11 section mismatch(es). > > To see full details build your kernel with: > > 'make CONFIG_DEBUG_SECTION_MISMATCH=y' > > .tmp_kallsyms1.S:1:23: error: asm/types.h: No such file or directory > > > > I have dropped the kbuild tree for today. > > Fixed. Thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* linux-next: kbuild tree build failure
@ 2008-11-26 4:42 Stephen Rothwell
2008-11-26 21:06 ` Sam Ravnborg
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2008-11-26 4:42 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hi Sam,
Today's linux-next build (x86_64 allmodconfig) failed like this:
In file included from arch/x86/include/asm/processor.h:15,
from include/linux/prefetch.h:14,
from include/linux/list.h:6,
from include/linux/module.h:9,
from kernel/configs.mod.c:1:
arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'
and went rapidly down hill from there.
I have dropped the kbuild tree again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: linux-next: kbuild tree build failure 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 0 siblings, 2 replies; 33+ messages in thread From: Sam Ravnborg @ 2008-11-26 21:06 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next On Wed, Nov 26, 2008 at 03:42:06PM +1100, Stephen Rothwell wrote: > Hi Sam, > > Today's linux-next build (x86_64 allmodconfig) failed like this: > > In file included from arch/x86/include/asm/processor.h:15, > from include/linux/prefetch.h:14, > from include/linux/list.h:6, > from include/linux/module.h:9, > from kernel/configs.mod.c:1: > arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct' > > and went rapidly down hill from there. This bug puzzeled me for a while... It triggers only when we do make O=... builds (which I did not do for a total build myself) But the flags are the same but in different order before/after my patch. Moving -D__KERNEL__ to be present earlier on the commandline fixed the build but it did not explain why it worked in the non O=... case. So I had to look for something else. I noticed that I had the following options in the O=... case: -I/full/path/ -I -D__KERNEL__ And there I had the bug. There is an optional space between -I and the path, so in this case gcc assume the path for the empty -I is "-D__KERNEL__" and we looses the -D__KERNEL__ definition - not good. But why had we not seen this before? Before it looked like this: -I/full/path/ -I -Wall so in the old case we lost the "-Wall" option. But as this bug only manifest itself when building the module.mod.o file then it is of no importance and not something I need to go back and fix in older kernels. I will cook up a fix tomorrow if day-time job does not become night-time. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-11-26 21:06 ` Sam Ravnborg @ 2008-11-26 23:49 ` Stephen Rothwell 2008-12-03 0:36 ` Stephen Rothwell 1 sibling, 0 replies; 33+ messages in thread From: Stephen Rothwell @ 2008-11-26 23:49 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next [-- Attachment #1: Type: text/plain, Size: 290 bytes --] Hi Sam, On Wed, 26 Nov 2008 22:06:57 +0100 Sam Ravnborg <sam@ravnborg.org> wrote: > > I will cook up a fix tomorrow if day-time job does not become night-time. OK, thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 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 1 sibling, 1 reply; 33+ messages in thread From: Stephen Rothwell @ 2008-12-03 0:36 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next [-- Attachment #1: Type: text/plain, Size: 922 bytes --] Hi Sam, On Wed, 26 Nov 2008 22:06:57 +0100 Sam Ravnborg <sam@ravnborg.org> wrote: > > On Wed, Nov 26, 2008 at 03:42:06PM +1100, Stephen Rothwell wrote: > > Hi Sam, > > > > Today's linux-next build (x86_64 allmodconfig) failed like this: > > > > In file included from arch/x86/include/asm/processor.h:15, > > from include/linux/prefetch.h:14, > > from include/linux/list.h:6, > > from include/linux/module.h:9, > > from kernel/configs.mod.c:1: > > arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct' > > > > and went rapidly down hill from there. > > I will cook up a fix tomorrow if day-time job does not become night-time. I am still getting the same errors ... -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2008-12-03 0:36 ` Stephen Rothwell @ 2008-12-03 9:46 ` Sam Ravnborg 0 siblings, 0 replies; 33+ messages in thread From: Sam Ravnborg @ 2008-12-03 9:46 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next On Wed, Dec 03, 2008 at 11:36:50AM +1100, Stephen Rothwell wrote: > Hi Sam, > > On Wed, 26 Nov 2008 22:06:57 +0100 Sam Ravnborg <sam@ravnborg.org> wrote: > > > > On Wed, Nov 26, 2008 at 03:42:06PM +1100, Stephen Rothwell wrote: > > > Hi Sam, > > > > > > Today's linux-next build (x86_64 allmodconfig) failed like this: > > > > > > In file included from arch/x86/include/asm/processor.h:15, > > > from include/linux/prefetch.h:14, > > > from include/linux/list.h:6, > > > from include/linux/module.h:9, > > > from kernel/configs.mod.c:1: > > > arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct' > > > > > > and went rapidly down hill from there. > > > > I will cook up a fix tomorrow if day-time job does not become night-time. > > I am still getting the same errors ... I have been concentrating (used all my spare time) on sparc unification. Will fix this soonish. I need to reshuffle a few patches nothing major. But it will take me a few hours. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* linux-next: kbuild tree build failure
@ 2009-05-05 1:17 Stephen Rothwell
2009-05-05 6:35 ` Jan Beulich
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2009-05-05 1:17 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, Jan Beulich, Steven Whitehouse
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
Hi Sam,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
fs/nfs/nfsroot.c:400: error: __setup_str_nfs_root_setup causes a section type conflict
We get these occasionally on powerpc builds - Usually from
EXPORT_SYMBOLS. Though I was hoping that using a newer compiler would
fix that (I am now compiling with gcc 4.4.0).
Direct cause is commit efbe795f5f63b74ed642e196518907355aa94bd7
("initconst adjustments").
OK, looking at the preprocessor output, I see we have a previous variable
(static match_table_t __initconst tokens) with __attribute__ ((__section__
(".init.rodata"))) but it is not const ... (This came from commit
a447c0932445f92ce6f4c1bd020f62c5097a7842 "vfs: Use const for kernel
parser table" which changed "tokens" from __initdata to __initconst. Not
using "const" seems deliberate, but the changelog does not include enough
information as to why.)
So, I will revert the above commit for today to allow it to be "improved"
by also fixing the tokens variable definition above. Of course there may
be other places where such mixed definitions exist.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: linux-next: kbuild tree build failure 2009-05-05 1:17 Stephen Rothwell @ 2009-05-05 6:35 ` Jan Beulich 2009-05-05 6:43 ` Sam Ravnborg 0 siblings, 1 reply; 33+ messages in thread From: Jan Beulich @ 2009-05-05 6:35 UTC (permalink / raw) To: Stephen Rothwell, Sam Ravnborg; +Cc: StevenWhitehouse, linux-next >>> Stephen Rothwell <sfr@canb.auug.org.au> 05.05.09 03:17 >>> >OK, looking at the preprocessor output, I see we have a previous variable >(static match_table_t __initconst tokens) with __attribute__ ((__section__ >(".init.rodata"))) but it is not const ... (This came from commit >a447c0932445f92ce6f4c1bd020f62c5097a7842 "vfs: Use const for kernel >parser table" which changed "tokens" from __initdata to __initconst. Not >using "const" seems deliberate, but the changelog does not include enough >information as to why.) > >So, I will revert the above commit for today to allow it to be "improved" >by also fixing the tokens variable definition above. Of course there may >be other places where such mixed definitions exist. That is the downside of not folding the 'const' modifier into the __initconst annotation. It is *always* an error to annotate something __initconst but not also make it const. Jan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2009-05-05 6:35 ` Jan Beulich @ 2009-05-05 6:43 ` Sam Ravnborg 2009-05-05 7:04 ` Jan Beulich 0 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2009-05-05 6:43 UTC (permalink / raw) To: Jan Beulich; +Cc: Stephen Rothwell, StevenWhitehouse, linux-next On Tue, May 05, 2009 at 07:35:02AM +0100, Jan Beulich wrote: > >>> Stephen Rothwell <sfr@canb.auug.org.au> 05.05.09 03:17 >>> > >OK, looking at the preprocessor output, I see we have a previous variable > >(static match_table_t __initconst tokens) with __attribute__ ((__section__ > >(".init.rodata"))) but it is not const ... (This came from commit > >a447c0932445f92ce6f4c1bd020f62c5097a7842 "vfs: Use const for kernel > >parser table" which changed "tokens" from __initdata to __initconst. Not > >using "const" seems deliberate, but the changelog does not include enough > >information as to why.) > > > >So, I will revert the above commit for today to allow it to be "improved" > >by also fixing the tokens variable definition above. Of course there may > >be other places where such mixed definitions exist. > > That is the downside of not folding the 'const' modifier into the __initconst > annotation. It is *always* an error to annotate something __initconst but > not also make it const. But if we folded const in __initconst would this be correct: drivers/net/eql.c:static const char version[] __initconst = ? It is now: static const char version[] = ... And will become: static char version[] const = gcc does not like the latter: $ cat jan.c: static const char version[] = "oldstuff"; static char version2[] const = "newstuff"; void foo(const char bar[]) { } void baz() { foo(version); foo(version2); } $ gcc jan.c: jan.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const' jan.c: In function 'baz': jan.c:11: error: 'version2' undeclared (first use in this function) jan.c:11: error: (Each undeclared identifier is reported only once jan.c:11: error: for each function it appears in.) Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2009-05-05 6:43 ` Sam Ravnborg @ 2009-05-05 7:04 ` Jan Beulich 0 siblings, 0 replies; 33+ messages in thread From: Jan Beulich @ 2009-05-05 7:04 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Stephen Rothwell, StevenWhitehouse, linux-next >>> Sam Ravnborg <sam@ravnborg.org> 05.05.09 08:43 >>> >On Tue, May 05, 2009 at 07:35:02AM +0100, Jan Beulich wrote: >> That is the downside of not folding the 'const' modifier into the __initconst >> annotation. It is *always* an error to annotate something __initconst but >> not also make it const. > >But if we folded const in __initconst would this be correct: > >drivers/net/eql.c:static const char version[] __initconst = No, of course not. __initconst would need to go in the place where const is now. My original patch (from really long ago) did this, but you didn't like that combination. Changing to such a model now (where we already have quite a number of uses of __initconst) is certainly going to be painful, so I'm not sure it's worth it. And if you would think now we should nevertheless convert, we'd have to first check whether declarations of more than one variable with a single declaration works with all supported gcc versions (since there are a number of caveats with how __attribute__() annotations are handled depending on their placement) - it may well be that there would need to be a one-variable-per-declaration constraint on users of __initconst & Co. Jan ^ permalink raw reply [flat|nested] 33+ messages in thread
* linux-next: kbuild tree build failure
@ 2009-06-09 1:48 Stephen Rothwell
2009-06-09 16:15 ` Sam Ravnborg
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2009-06-09 1:48 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
Hi Sam,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
powerpc-linux-ld:arch/powerpc/kernel/vmlinux.lds:190: syntax error
Caused by commit 59d59d97e34c6593bec43666679b28da5d583958 ("Improve
vmlinux.lds.h support for arch specific linker scripts") which was
clearly not build tested - don't do that! There is a missing \ at the end
of a line in the definition of the HEAD_SECTION macro.
I have used the version of the kbuild tree from next-20090605.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: linux-next: kbuild tree build failure 2009-06-09 1:48 Stephen Rothwell @ 2009-06-09 16:15 ` Sam Ravnborg 2009-06-09 16:19 ` Stephen Rothwell 0 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2009-06-09 16:15 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, linux-kernel On Tue, Jun 09, 2009 at 11:48:20AM +1000, Stephen Rothwell wrote: > Hi Sam, > > Today's linux-next build (powerpc ppc64_defconfig) failed like this: > > powerpc-linux-ld:arch/powerpc/kernel/vmlinux.lds:190: syntax error > > Caused by commit 59d59d97e34c6593bec43666679b28da5d583958 ("Improve > vmlinux.lds.h support for arch specific linker scripts") which was > clearly not build tested - don't do that! There is a missing \ at the end > of a line in the definition of the HEAD_SECTION macro. > > I have used the version of the kbuild tree from next-20090605. My bad - obviously. I will fix when the kids are sleeping (as in a few hours from now). Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2009-06-09 16:15 ` Sam Ravnborg @ 2009-06-09 16:19 ` Stephen Rothwell 2009-06-09 21:04 ` Sam Ravnborg 0 siblings, 1 reply; 33+ messages in thread From: Stephen Rothwell @ 2009-06-09 16:19 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 321 bytes --] Hi Sam, On Tue, 9 Jun 2009 18:15:12 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > I will fix when the kids are sleeping (as in a few hours from now). Thanks. I won't be needing it for about 7 hours. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2009-06-09 16:19 ` Stephen Rothwell @ 2009-06-09 21:04 ` Sam Ravnborg 2009-06-09 23:27 ` Stephen Rothwell 0 siblings, 1 reply; 33+ messages in thread From: Sam Ravnborg @ 2009-06-09 21:04 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, linux-kernel On Wed, Jun 10, 2009 at 02:19:59AM +1000, Stephen Rothwell wrote: > Hi Sam, > > On Tue, 9 Jun 2009 18:15:12 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > > > I will fix when the kids are sleeping (as in a few hours from now). > > Thanks. I won't be needing it for about 7 hours. Fixed now (and build tested all changes this time). Thanks, Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: linux-next: kbuild tree build failure 2009-06-09 21:04 ` Sam Ravnborg @ 2009-06-09 23:27 ` Stephen Rothwell 0 siblings, 0 replies; 33+ messages in thread From: Stephen Rothwell @ 2009-06-09 23:27 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-next, linux-kernel [-- Attachment #1: Type: text/plain, Size: 266 bytes --] Hi Sam, On Tue, 9 Jun 2009 23:04:27 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > Fixed now (and build tested all changes this time). Excellent! -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* linux-next: kbuild tree build failure
@ 2009-10-14 1:20 Stephen Rothwell
2009-10-14 7:43 ` Sam Ravnborg
0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2009-10-14 1:20 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-next, linux-kernel, David S. Miller, Arnaldo Carvalho de Melo
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Hi Sam,
Today's linux-next build (x86_64 allmodconfig) failed like this:
In file included from arch/x86/kernel/syscall_64.c:28:
arch/x86/include/asm/unistd_64.h:665: error: array index in initializer exceeds array bounds
arch/x86/include/asm/unistd_64.h:665: error: (near initialization for 'sys_call_table')
arch/x86/include/asm/unistd_64.h:665: warning: excess elements in array initializer
arch/x86/include/asm/unistd_64.h:665: warning: (near initialization for 'sys_call_table')
Exposed by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net:
Introduce recvmmsg socket syscall"). include/asm/asm-offsets.h did not
get updated even though arch/x86/kernel/asm-offsets.s did. Ah,
generated/asm-offsets.h has been updated but my build tree still has the
(generated in a previous build) include/asm/asm-offsets.h which is
presumably found before the new arch/x86/include/asm/asm-offsets.h
introduced by commit fe5ff47a5d79ca99ec7e3155eb19469b44905b2c ("kbuild:
move asm-offsets.h to include/generated").
Sam, can you think of a better migration path?
I removed include/asm/asm_offsets.h from my object tree and everything
builds ok.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: linux-next: kbuild tree build failure 2009-10-14 1:20 Stephen Rothwell @ 2009-10-14 7:43 ` Sam Ravnborg 0 siblings, 0 replies; 33+ messages in thread From: Sam Ravnborg @ 2009-10-14 7:43 UTC (permalink / raw) To: Stephen Rothwell Cc: linux-next, linux-kernel, David S. Miller, Arnaldo Carvalho de Melo On Wed, Oct 14, 2009 at 12:20:24PM +1100, Stephen Rothwell wrote: > Hi Sam, > > Today's linux-next build (x86_64 allmodconfig) failed like this: > > In file included from arch/x86/kernel/syscall_64.c:28: > arch/x86/include/asm/unistd_64.h:665: error: array index in initializer exceeds array bounds > arch/x86/include/asm/unistd_64.h:665: error: (near initialization for 'sys_call_table') > arch/x86/include/asm/unistd_64.h:665: warning: excess elements in array initializer > arch/x86/include/asm/unistd_64.h:665: warning: (near initialization for 'sys_call_table') > > Exposed by commit a2e2725541fad72416326798c2d7fa4dafb7d337 ("net: > Introduce recvmmsg socket syscall"). include/asm/asm-offsets.h did not > get updated even though arch/x86/kernel/asm-offsets.s did. Ah, > generated/asm-offsets.h has been updated but my build tree still has the > (generated in a previous build) include/asm/asm-offsets.h which is > presumably found before the new arch/x86/include/asm/asm-offsets.h > introduced by commit fe5ff47a5d79ca99ec7e3155eb19469b44905b2c ("kbuild: > move asm-offsets.h to include/generated"). > > Sam, can you think of a better migration path? I once thought of forefully removing include/asm to avoid this. Maybe we could let "make clean" remove include/asm - I expect this would have helped in this situation? I'm planning to redo the serie within the next couple of weeks anyway. Sam ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2009-10-14 7:44 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-07 8:40 linux-next: kbuild tree build failure Stephen Rothwell 2008-07-07 12:51 ` Sam Ravnborg 2008-07-07 13:08 ` Stephen Rothwell 2008-07-07 16:13 ` Roman Zippel 2008-07-07 21:01 ` Sam Ravnborg 2008-07-07 23:36 ` Michael Ellerman 2008-07-08 2:55 ` Roman Zippel 2008-07-10 0:51 ` Michael Ellerman 2008-07-10 14:59 ` Roman Zippel 2008-07-08 21:19 ` Sam Ravnborg 2008-07-10 14:52 ` Roman Zippel 2008-07-25 4:13 ` Stephen Rothwell 2008-07-26 10:06 ` Sam Ravnborg 2008-07-26 12:40 ` Stephen Rothwell 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).