Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann wrote: > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> >> > wrote: > >> >> > > > >> >> > > All now queued up in the stable trees, thanks. > >> >> > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> >> > warnings > >> >> > and this one that continues to puzzle me. > >> >> > > >> >> > /bin/sh: 1: > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> >> > Permission denied > >> >> > >> >> Jiri? Josh? > >> > > >> > hum, looks like it imight be related to this fix we did for perf: > >> > abb26210a395 perf tools: Force fixdep compilation at the start of the > >> > build > >> > > >> > it's forcing fixdep to be build as first.. having it as a simple > >> > dependency > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > >> > cpu > >> > servers, and executed unfinished binary, hence the permission fail > >> > >> It's probably another variation of this bug, but the commit you cite got > >> merged > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > did for perf in objtool, but a cleaner way would be to generalize it for all > of > tools/, right? This is a shot in the dark, since I don't have a way to recreate, but can you try the following patch? This should make sure that objtool only tries to build fixdep once. diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include index ad22e4e..179f4f0 100644 --- a/tools/build/Makefile.include +++ b/tools/build/Makefile.include @@ -1,6 +1,8 @@ build := -f $(srctree)/tools/build/Makefile.build dir=. obj -fixdep: +fixdep: $(OUTPUT)fixdep + +$(OUTPUT)fixdep: $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= $(OUTPUT)fixdep .PHONY: fixdep
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann wrote: > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> >> > wrote: > >> >> > > > >> >> > > All now queued up in the stable trees, thanks. > >> >> > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> >> > warnings > >> >> > and this one that continues to puzzle me. > >> >> > > >> >> > /bin/sh: 1: > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> >> > Permission denied > >> >> > >> >> Jiri? Josh? > >> > > >> > hum, looks like it imight be related to this fix we did for perf: > >> > abb26210a395 perf tools: Force fixdep compilation at the start of the > >> > build > >> > > >> > it's forcing fixdep to be build as first.. having it as a simple > >> > dependency > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > >> > cpu > >> > servers, and executed unfinished binary, hence the permission fail > >> > >> It's probably another variation of this bug, but the commit you cite got > >> merged > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > did for perf in objtool, but a cleaner way would be to generalize it for all > of > tools/, right? This is a shot in the dark, since I don't have a way to recreate, but can you try the following patch? This should make sure that objtool only tries to build fixdep once. diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include index ad22e4e..179f4f0 100644 --- a/tools/build/Makefile.include +++ b/tools/build/Makefile.include @@ -1,6 +1,8 @@ build := -f $(srctree)/tools/build/Makefile.build dir=. obj -fixdep: +fixdep: $(OUTPUT)fixdep + +$(OUTPUT)fixdep: $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= $(OUTPUT)fixdep .PHONY: fixdep
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann wrote: > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> >> > wrote: > >> >> > > > >> >> > > All now queued up in the stable trees, thanks. > >> >> > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> >> > warnings > >> >> > and this one that continues to puzzle me. > >> >> > > >> >> > /bin/sh: 1: > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> >> > Permission denied > >> >> > >> >> Jiri? Josh? > >> > > >> > hum, looks like it imight be related to this fix we did for perf: > >> > abb26210a395 perf tools: Force fixdep compilation at the start of the > >> > build > >> > > >> > it's forcing fixdep to be build as first.. having it as a simple > >> > dependency > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > >> > cpu > >> > servers, and executed unfinished binary, hence the permission fail > >> > >> It's probably another variation of this bug, but the commit you cite got > >> merged > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > did for perf in objtool, but a cleaner way would be to generalize it for all > of > tools/, right? > > Arnd i came up quickly with attached change.. not too much tested, but basically it's the idea applied to objtool looks like we could generalize some of those pieces, I'll try to look at it next week if nobody beats me to it ;-) thanks, jirka --- diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile index 3d1c3b5b5150..a00942fbe43b 100644 --- a/tools/lib/subcmd/Makefile +++ b/tools/lib/subcmd/Makefile @@ -1,6 +1,18 @@ include ../../scripts/Makefile.include include ../../scripts/utilities.mak# QUIET_CLEAN +all: + +config := 1 + +NON_CONFIG_TARGETS := clean + +ifdef MAKECMDGOALS +ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),) + config := 0 +endif +endif + ifeq ($(srctree),) srctree := $(patsubst %/,%,$(dir $(CURDIR))) srctree := $(patsubst %/,%,$(dir $(srctree))) @@ -45,7 +57,24 @@ all: export srctree OUTPUT CC LD CFLAGS V include $(srctree)/tools/build/Makefile.include -all: fixdep $(LIBFILE) +ifdef FIXDEP + force_fixdep := 0 +else + force_fixdep := $(config) +endif + +ifeq ($(force_fixdep),1) +goals := $(filter-out all sub-make, $(MAKECMDGOALS)) + +$(goals) all: sub-make + +sub-make: fixdep + $(Q)$(MAKE) FIXDEP=1 -f Makefile $(goals) + +else # force_fixdep + + +all: $(LIBFILE) $(SUBCMD_IN): FORCE @$(MAKE) $(build)=libsubcmd @@ -59,4 +88,6 @@ clean: FORCE: -.PHONY: clean FORCE +endif # force_fixdep + +.PHONY: clean FORCE sub-make diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index 27e019c09bd2..8c78a9114ab5 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -1,6 +1,18 @@ include ../scripts/Makefile.include include ../scripts/Makefile.arch +all: + +config := 1 + +NON_CONFIG_TARGETS := clean + +ifdef MAKECMDGOALS +ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),) + config := 0 +endif +endif + ifeq ($(ARCH),x86_64) ARCH := x86 endif @@ -22,8 +34,6 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a OBJTOOL:= $(OUTPUT)objtool OBJTOOL_IN := $(OBJTOOL)-in.o -all: $(OBJTOOL) - INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi CFLAGS += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES) LDFLAGS += -lelf $(LIBSUBCMD) @@ -36,7 +46,25 @@ AWK = awk export srctree OUTPUT CFLAGS SRCARCH AWK include $(srctree)/tools/build/Makefile.include -$(OBJTOOL_IN): fixdep FORCE +ifdef FIXDEP + force_fixdep := 0 +else + force_fixdep := $(config) +endif + +ifeq ($(force_fixdep),1) +goals := $(filter-out all sub-make, $(MAKECMDGOALS)) + +$(goals) all: sub-make + +sub-make: fixdep + $(Q)$(MAKE) FIXDEP=1 -f Makefile $(goals) + +else # force_fixdep + +all: $(OBJTOOL) + +$(OBJTOOL_IN): FORCE @$(MAKE) $(build)=objtool # Busybox's diff doesn't have -I, avoid warning in that case @@ -55,7 +83,7 @@ $(OBJTOOL): $(LIBSUBCMD) $(OBJTOOL_IN) $(QUIET_LINK)$(CC) $(OBJTOOL_IN) $(LDFLAGS) -o $@ -$(LIBSUBCMD): fixdep FORCE +$(LIBSUBCMD): FORCE $(Q)$(MAKE) -C $(SUBCMD_SRCDIR) OUTPUT=$(LIBSUBCMD_OUTPUT) clean: @@ -65,4 +93,6 @@ clean: FORCE: -.PHONY: clean FORCE
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann wrote: > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> >> > wrote: > >> >> > > > >> >> > > All now queued up in the stable trees, thanks. > >> >> > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> >> > warnings > >> >> > and this one that continues to puzzle me. > >> >> > > >> >> > /bin/sh: 1: > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> >> > Permission denied > >> >> > >> >> Jiri? Josh? > >> > > >> > hum, looks like it imight be related to this fix we did for perf: > >> > abb26210a395 perf tools: Force fixdep compilation at the start of the > >> > build > >> > > >> > it's forcing fixdep to be build as first.. having it as a simple > >> > dependency > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > >> > cpu > >> > servers, and executed unfinished binary, hence the permission fail > >> > >> It's probably another variation of this bug, but the commit you cite got > >> merged > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > did for perf in objtool, but a cleaner way would be to generalize it for all > of > tools/, right? > > Arnd i came up quickly with attached change.. not too much tested, but basically it's the idea applied to objtool looks like we could generalize some of those pieces, I'll try to look at it next week if nobody beats me to it ;-) thanks, jirka --- diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile index 3d1c3b5b5150..a00942fbe43b 100644 --- a/tools/lib/subcmd/Makefile +++ b/tools/lib/subcmd/Makefile @@ -1,6 +1,18 @@ include ../../scripts/Makefile.include include ../../scripts/utilities.mak# QUIET_CLEAN +all: + +config := 1 + +NON_CONFIG_TARGETS := clean + +ifdef MAKECMDGOALS +ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),) + config := 0 +endif +endif + ifeq ($(srctree),) srctree := $(patsubst %/,%,$(dir $(CURDIR))) srctree := $(patsubst %/,%,$(dir $(srctree))) @@ -45,7 +57,24 @@ all: export srctree OUTPUT CC LD CFLAGS V include $(srctree)/tools/build/Makefile.include -all: fixdep $(LIBFILE) +ifdef FIXDEP + force_fixdep := 0 +else + force_fixdep := $(config) +endif + +ifeq ($(force_fixdep),1) +goals := $(filter-out all sub-make, $(MAKECMDGOALS)) + +$(goals) all: sub-make + +sub-make: fixdep + $(Q)$(MAKE) FIXDEP=1 -f Makefile $(goals) + +else # force_fixdep + + +all: $(LIBFILE) $(SUBCMD_IN): FORCE @$(MAKE) $(build)=libsubcmd @@ -59,4 +88,6 @@ clean: FORCE: -.PHONY: clean FORCE +endif # force_fixdep + +.PHONY: clean FORCE sub-make diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index 27e019c09bd2..8c78a9114ab5 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -1,6 +1,18 @@ include ../scripts/Makefile.include include ../scripts/Makefile.arch +all: + +config := 1 + +NON_CONFIG_TARGETS := clean + +ifdef MAKECMDGOALS +ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),) + config := 0 +endif +endif + ifeq ($(ARCH),x86_64) ARCH := x86 endif @@ -22,8 +34,6 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a OBJTOOL:= $(OUTPUT)objtool OBJTOOL_IN := $(OBJTOOL)-in.o -all: $(OBJTOOL) - INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi CFLAGS += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES) LDFLAGS += -lelf $(LIBSUBCMD) @@ -36,7 +46,25 @@ AWK = awk export srctree OUTPUT CFLAGS SRCARCH AWK include $(srctree)/tools/build/Makefile.include -$(OBJTOOL_IN): fixdep FORCE +ifdef FIXDEP + force_fixdep := 0 +else + force_fixdep := $(config) +endif + +ifeq ($(force_fixdep),1) +goals := $(filter-out all sub-make, $(MAKECMDGOALS)) + +$(goals) all: sub-make + +sub-make: fixdep + $(Q)$(MAKE) FIXDEP=1 -f Makefile $(goals) + +else # force_fixdep + +all: $(OBJTOOL) + +$(OBJTOOL_IN): FORCE @$(MAKE) $(build)=objtool # Busybox's diff doesn't have -I, avoid warning in that case @@ -55,7 +83,7 @@ $(OBJTOOL): $(LIBSUBCMD) $(OBJTOOL_IN) $(QUIET_LINK)$(CC) $(OBJTOOL_IN) $(LDFLAGS) -o $@ -$(LIBSUBCMD): fixdep FORCE +$(LIBSUBCMD): FORCE $(Q)$(MAKE) -C $(SUBCMD_SRCDIR) OUTPUT=$(LIBSUBCMD_OUTPUT) clean: @@ -65,4 +93,6 @@ clean: FORCE: -.PHONY: clean FORCE +endif # force_fixdep + +.PHONY: clean FORCE sub-make
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 12:46:00PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 16, 2017 at 04:17:04PM +0100, Jiri Olsa escreveu: > > On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > > > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > > > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > > > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > > > >> It's probably another variation of this bug, but the commit you cite > > > > >> got merged > > > > >> into 4.10-rc1, while the problem still persists in mainline > > > > >> (4.11-rc2+). > > > > > > the problem is in objtool build right? the fix was for perf build > > > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate > > > > what you > > > > did for perf in objtool, but a cleaner way would be to generalize it > > > > for all of > > > > tools/, right? > > > right, the thing is that objtool is standalone application like perf, > > and before their builds can go the 'fixdep' needs to be there.. that's > > a condition to use the tools/build framework > > > not sure how offensive it'd be to current Makefiles if we come with some > > generalized code to do that.. I'll think about it, but I think we might > > be better of the way we are now > > > > Humm, can't we have just one fixdep? > > > we have.. it's just the matter who will build it first ;-) > > Ok, I haven't said "can't we have just one fixdep?", what I really said > was "can't we make sure we don't have races building it?" ;-) I hope so ;-) but so far I cannot think of anything better than what was introduced in: abb26210a395 perf tools: Force fixdep compilation at the start of the build jirka
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 12:46:00PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 16, 2017 at 04:17:04PM +0100, Jiri Olsa escreveu: > > On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > > > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > > > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > > > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > > > >> It's probably another variation of this bug, but the commit you cite > > > > >> got merged > > > > >> into 4.10-rc1, while the problem still persists in mainline > > > > >> (4.11-rc2+). > > > > > > the problem is in objtool build right? the fix was for perf build > > > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate > > > > what you > > > > did for perf in objtool, but a cleaner way would be to generalize it > > > > for all of > > > > tools/, right? > > > right, the thing is that objtool is standalone application like perf, > > and before their builds can go the 'fixdep' needs to be there.. that's > > a condition to use the tools/build framework > > > not sure how offensive it'd be to current Makefiles if we come with some > > generalized code to do that.. I'll think about it, but I think we might > > be better of the way we are now > > > > Humm, can't we have just one fixdep? > > > we have.. it's just the matter who will build it first ;-) > > Ok, I haven't said "can't we have just one fixdep?", what I really said > was "can't we make sure we don't have races building it?" ;-) I hope so ;-) but so far I cannot think of anything better than what was introduced in: abb26210a395 perf tools: Force fixdep compilation at the start of the build jirka
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
Em Thu, Mar 16, 2017 at 04:17:04PM +0100, Jiri Olsa escreveu: > On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > > >> It's probably another variation of this bug, but the commit you cite > > > >> got merged > > > >> into 4.10-rc1, while the problem still persists in mainline > > > >> (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what > > > you > > > did for perf in objtool, but a cleaner way would be to generalize it for > > > all of > > > tools/, right? > right, the thing is that objtool is standalone application like perf, > and before their builds can go the 'fixdep' needs to be there.. that's > a condition to use the tools/build framework > not sure how offensive it'd be to current Makefiles if we come with some > generalized code to do that.. I'll think about it, but I think we might > be better of the way we are now > > Humm, can't we have just one fixdep? > we have.. it's just the matter who will build it first ;-) Ok, I haven't said "can't we have just one fixdep?", what I really said was "can't we make sure we don't have races building it?" ;-) - Arnaldo
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
Em Thu, Mar 16, 2017 at 04:17:04PM +0100, Jiri Olsa escreveu: > On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > > >> It's probably another variation of this bug, but the commit you cite > > > >> got merged > > > >> into 4.10-rc1, while the problem still persists in mainline > > > >> (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what > > > you > > > did for perf in objtool, but a cleaner way would be to generalize it for > > > all of > > > tools/, right? > right, the thing is that objtool is standalone application like perf, > and before their builds can go the 'fixdep' needs to be there.. that's > a condition to use the tools/build framework > not sure how offensive it'd be to current Makefiles if we come with some > generalized code to do that.. I'll think about it, but I think we might > be better of the way we are now > > Humm, can't we have just one fixdep? > we have.. it's just the matter who will build it first ;-) Ok, I haven't said "can't we have just one fixdep?", what I really said was "can't we make sure we don't have races building it?" ;-) - Arnaldo
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo > > >> > wrote: > > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > > >> >> > wrote: > > >> >> > > > > >> >> > > All now queued up in the stable trees, thanks. > > >> >> > > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > > >> >> > warnings > > >> >> > and this one that continues to puzzle me. > > >> >> > > > >> >> > /bin/sh: 1: > > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > > >> >> > Permission denied > > >> >> > > >> >> Jiri? Josh? > > >> > > > >> > hum, looks like it imight be related to this fix we did for perf: > > >> > abb26210a395 perf tools: Force fixdep compilation at the start of > > >> > the build > > >> > > > >> > it's forcing fixdep to be build as first.. having it as a simple > > >> > dependency > > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > > >> > cpu > > >> > servers, and executed unfinished binary, hence the permission fail > > >> > > >> It's probably another variation of this bug, but the commit you cite got > > >> merged > > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > > > the problem is in objtool build right? the fix was for perf build > > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > > did for perf in objtool, but a cleaner way would be to generalize it for > > all of > > tools/, right? right, the thing is that objtool is standalone application like perf, and before their builds can go the 'fixdep' needs to be there.. that's a condition to use the tools/build framework not sure how offensive it'd be to current Makefiles if we come with some generalized code to do that.. I'll think about it, but I think we might be better of the way we are now > > Humm, can't we have just one fixdep? we have.. it's just the matter who will build it first ;-) jirka
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo > > >> > wrote: > > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > > >> >> > wrote: > > >> >> > > > > >> >> > > All now queued up in the stable trees, thanks. > > >> >> > > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > > >> >> > warnings > > >> >> > and this one that continues to puzzle me. > > >> >> > > > >> >> > /bin/sh: 1: > > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > > >> >> > Permission denied > > >> >> > > >> >> Jiri? Josh? > > >> > > > >> > hum, looks like it imight be related to this fix we did for perf: > > >> > abb26210a395 perf tools: Force fixdep compilation at the start of > > >> > the build > > >> > > > >> > it's forcing fixdep to be build as first.. having it as a simple > > >> > dependency > > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > > >> > cpu > > >> > servers, and executed unfinished binary, hence the permission fail > > >> > > >> It's probably another variation of this bug, but the commit you cite got > > >> merged > > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > > > the problem is in objtool build right? the fix was for perf build > > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > > did for perf in objtool, but a cleaner way would be to generalize it for > > all of > > tools/, right? right, the thing is that objtool is standalone application like perf, and before their builds can go the 'fixdep' needs to be there.. that's a condition to use the tools/build framework not sure how offensive it'd be to current Makefiles if we come with some generalized code to do that.. I'll think about it, but I think we might be better of the way we are now > > Humm, can't we have just one fixdep? we have.. it's just the matter who will build it first ;-) jirka
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> >> > wrote: > >> >> > > > >> >> > > All now queued up in the stable trees, thanks. > >> >> > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> >> > warnings > >> >> > and this one that continues to puzzle me. > >> >> > > >> >> > /bin/sh: 1: > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> >> > Permission denied > >> >> > >> >> Jiri? Josh? > >> > > >> > hum, looks like it imight be related to this fix we did for perf: > >> > abb26210a395 perf tools: Force fixdep compilation at the start of the > >> > build > >> > > >> > it's forcing fixdep to be build as first.. having it as a simple > >> > dependency > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > >> > cpu > >> > servers, and executed unfinished binary, hence the permission fail > >> > >> It's probably another variation of this bug, but the commit you cite got > >> merged > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > did for perf in objtool, but a cleaner way would be to generalize it for all > of > tools/, right? Humm, can't we have just one fixdep? - Arnaldo
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu: > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> >> > wrote: > >> >> > > > >> >> > > All now queued up in the stable trees, thanks. > >> >> > > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> >> > warnings > >> >> > and this one that continues to puzzle me. > >> >> > > >> >> > /bin/sh: 1: > >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> >> > Permission denied > >> >> > >> >> Jiri? Josh? > >> > > >> > hum, looks like it imight be related to this fix we did for perf: > >> > abb26210a395 perf tools: Force fixdep compilation at the start of the > >> > build > >> > > >> > it's forcing fixdep to be build as first.. having it as a simple > >> > dependency > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high > >> > cpu > >> > servers, and executed unfinished binary, hence the permission fail > >> > >> It's probably another variation of this bug, but the commit you cite got > >> merged > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > > > the problem is in objtool build right? the fix was for perf build > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you > did for perf in objtool, but a cleaner way would be to generalize it for all > of > tools/, right? Humm, can't we have just one fixdep? - Arnaldo
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsawrote: > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh >> >> > wrote: >> >> > > >> >> > > All now queued up in the stable trees, thanks. >> >> > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size >> >> > warnings >> >> > and this one that continues to puzzle me. >> >> > >> >> > /bin/sh: 1: >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: >> >> > Permission denied >> >> >> >> Jiri? Josh? >> > >> > hum, looks like it imight be related to this fix we did for perf: >> > abb26210a395 perf tools: Force fixdep compilation at the start of the >> > build >> > >> > it's forcing fixdep to be build as first.. having it as a simple dependency >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu >> > servers, and executed unfinished binary, hence the permission fail >> >> It's probably another variation of this bug, but the commit you cite got >> merged >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > the problem is in objtool build right? the fix was for perf build Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you did for perf in objtool, but a cleaner way would be to generalize it for all of tools/, right? Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa wrote: > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh >> >> > wrote: >> >> > > >> >> > > All now queued up in the stable trees, thanks. >> >> > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size >> >> > warnings >> >> > and this one that continues to puzzle me. >> >> > >> >> > /bin/sh: 1: >> >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: >> >> > Permission denied >> >> >> >> Jiri? Josh? >> > >> > hum, looks like it imight be related to this fix we did for perf: >> > abb26210a395 perf tools: Force fixdep compilation at the start of the >> > build >> > >> > it's forcing fixdep to be build as first.. having it as a simple dependency >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu >> > servers, and executed unfinished binary, hence the permission fail >> >> It's probably another variation of this bug, but the commit you cite got >> merged >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). > > the problem is in objtool build right? the fix was for perf build Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you did for perf in objtool, but a cleaner way would be to generalize it for all of tools/, right? Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsawrote: > > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> > wrote: > >> > > > >> > > All now queued up in the stable trees, thanks. > >> > > >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> > warnings > >> > and this one that continues to puzzle me. > >> > > >> > /bin/sh: 1: > >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> > Permission denied > >> > >> Jiri? Josh? > > > > hum, looks like it imight be related to this fix we did for perf: > > abb26210a395 perf tools: Force fixdep compilation at the start of the > > build > > > > it's forcing fixdep to be build as first.. having it as a simple dependency > > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu > > servers, and executed unfinished binary, hence the permission fail > > It's probably another variation of this bug, but the commit you cite got > merged > into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). the problem is in objtool build right? the fix was for perf build jirka
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote: > On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh > >> > wrote: > >> > > > >> > > All now queued up in the stable trees, thanks. > >> > > >> > Like 4.9.y it builds clean except for a couple of stack frame size > >> > warnings > >> > and this one that continues to puzzle me. > >> > > >> > /bin/sh: 1: > >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > >> > Permission denied > >> > >> Jiri? Josh? > > > > hum, looks like it imight be related to this fix we did for perf: > > abb26210a395 perf tools: Force fixdep compilation at the start of the > > build > > > > it's forcing fixdep to be build as first.. having it as a simple dependency > > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu > > servers, and executed unfinished binary, hence the permission fail > > It's probably another variation of this bug, but the commit you cite got > merged > into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). the problem is in objtool build right? the fix was for perf build jirka
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsawrote: > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh wrote: >> > > >> > > All now queued up in the stable trees, thanks. >> > >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings >> > and this one that continues to puzzle me. >> > >> > /bin/sh: 1: >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: >> > Permission denied >> >> Jiri? Josh? > > hum, looks like it imight be related to this fix we did for perf: > abb26210a395 perf tools: Force fixdep compilation at the start of the build > > it's forcing fixdep to be build as first.. having it as a simple dependency > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu > servers, and executed unfinished binary, hence the permission fail It's probably another variation of this bug, but the commit you cite got merged into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa wrote: > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh wrote: >> > > >> > > All now queued up in the stable trees, thanks. >> > >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings >> > and this one that continues to puzzle me. >> > >> > /bin/sh: 1: >> > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: >> > Permission denied >> >> Jiri? Josh? > > hum, looks like it imight be related to this fix we did for perf: > abb26210a395 perf tools: Force fixdep compilation at the start of the build > > it's forcing fixdep to be build as first.. having it as a simple dependency > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu > servers, and executed unfinished binary, hence the permission fail It's probably another variation of this bug, but the commit you cite got merged into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+). Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > > On Wed, Mar 15, 2017 at 8:22 AM, gregkhwrote: > > > > > > All now queued up in the stable trees, thanks. > > > > Like 4.9.y it builds clean except for a couple of stack frame size warnings > > and this one that continues to puzzle me. > > > > /bin/sh: 1: > > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > > Permission denied > > Jiri? Josh? hum, looks like it imight be related to this fix we did for perf: abb26210a395 perf tools: Force fixdep compilation at the start of the build it's forcing fixdep to be build as first.. having it as a simple dependency (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu servers, and executed unfinished binary, hence the permission fail jirka > > - Arnaldo > > > https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log > > > > The same warning is referenced in this email: > > http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html > > > > but I can't figure out what patch is supposed to address it, or if that > > patch made it into mainline. > > > > Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not > > plain allmodconfig, maybe this could be related to rebuilding in the same > > object tree without "make clean". Also, all recent kernels (since December) > > until next-20170309 seem to be affected, but it does not show up on > > the latest linux-next (next-20170310). I don't seen anything in > > next-20170310 > > that could have addressed it, so it may also be a coincidence that we don't > > hit a certain race condition during build this time. > > > > Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going > > on here. > > > > Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > > On Wed, Mar 15, 2017 at 8:22 AM, gregkh wrote: > > > > > > All now queued up in the stable trees, thanks. > > > > Like 4.9.y it builds clean except for a couple of stack frame size warnings > > and this one that continues to puzzle me. > > > > /bin/sh: 1: > > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > > Permission denied > > Jiri? Josh? hum, looks like it imight be related to this fix we did for perf: abb26210a395 perf tools: Force fixdep compilation at the start of the build it's forcing fixdep to be build as first.. having it as a simple dependency (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu servers, and executed unfinished binary, hence the permission fail jirka > > - Arnaldo > > > https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log > > > > The same warning is referenced in this email: > > http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html > > > > but I can't figure out what patch is supposed to address it, or if that > > patch made it into mainline. > > > > Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not > > plain allmodconfig, maybe this could be related to rebuilding in the same > > object tree without "make clean". Also, all recent kernels (since December) > > until next-20170309 seem to be affected, but it does not show up on > > the latest linux-next (next-20170310). I don't seen anything in > > next-20170310 > > that could have addressed it, so it may also be a coincidence that we don't > > hit a certain race condition during build this time. > > > > Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going > > on here. > > > > Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > On Wed, Mar 15, 2017 at 8:22 AM, gregkhwrote: > > > > All now queued up in the stable trees, thanks. > > Like 4.9.y it builds clean except for a couple of stack frame size warnings > and this one that continues to puzzle me. > > /bin/sh: 1: > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > Permission denied Jiri? Josh? - Arnaldo > https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log > > The same warning is referenced in this email: > http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html > > but I can't figure out what patch is supposed to address it, or if that > patch made it into mainline. > > Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not > plain allmodconfig, maybe this could be related to rebuilding in the same > object tree without "make clean". Also, all recent kernels (since December) > until next-20170309 seem to be affected, but it does not show up on > the latest linux-next (next-20170310). I don't seen anything in next-20170310 > that could have addressed it, so it may also be a coincidence that we don't > hit a certain race condition during build this time. > > Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going > on here. > > Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu: > On Wed, Mar 15, 2017 at 8:22 AM, gregkh wrote: > > > > All now queued up in the stable trees, thanks. > > Like 4.9.y it builds clean except for a couple of stack frame size warnings > and this one that continues to puzzle me. > > /bin/sh: 1: > /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: > Permission denied Jiri? Josh? - Arnaldo > https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log > > The same warning is referenced in this email: > http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html > > but I can't figure out what patch is supposed to address it, or if that > patch made it into mainline. > > Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not > plain allmodconfig, maybe this could be related to rebuilding in the same > object tree without "make clean". Also, all recent kernels (since December) > until next-20170309 seem to be affected, but it does not show up on > the latest linux-next (next-20170310). I don't seen anything in next-20170310 > that could have addressed it, so it may also be a coincidence that we don't > hit a certain race condition during build this time. > > Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going > on here. > > Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Wed, Mar 15, 2017 at 8:22 AM, gregkhwrote: > > All now queued up in the stable trees, thanks. Like 4.9.y it builds clean except for a couple of stack frame size warnings and this one that continues to puzzle me. /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: Permission denied https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log The same warning is referenced in this email: http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html but I can't figure out what patch is supposed to address it, or if that patch made it into mainline. Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not plain allmodconfig, maybe this could be related to rebuilding in the same object tree without "make clean". Also, all recent kernels (since December) until next-20170309 seem to be affected, but it does not show up on the latest linux-next (next-20170310). I don't seen anything in next-20170310 that could have addressed it, so it may also be a coincidence that we don't hit a certain race condition during build this time. Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going on here. Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Wed, Mar 15, 2017 at 8:22 AM, gregkh wrote: > > All now queued up in the stable trees, thanks. Like 4.9.y it builds clean except for a couple of stack frame size warnings and this one that continues to puzzle me. /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep: Permission denied https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log The same warning is referenced in this email: http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html but I can't figure out what patch is supposed to address it, or if that patch made it into mainline. Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not plain allmodconfig, maybe this could be related to rebuilding in the same object tree without "make clean". Also, all recent kernels (since December) until next-20170309 seem to be affected, but it does not show up on the latest linux-next (next-20170310). I don't seen anything in next-20170310 that could have addressed it, so it may also be a coincidence that we don't hit a certain race condition during build this time. Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going on here. Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Tue, Feb 28, 2017 at 02:31:51PM +0100, Arnd Bergmann wrote: > On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org botwrote: > > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings > > A lot of fixes for these build problems have now landed in mainline, and > we could backport them as soon as they are considered stable enough. > If all of these make it into stable, we should have a clean build on MIPS and > ARM, and only the KASAN warnings remaining x86 and arm64. > > > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > > > Warnings: > > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than > > 1024 bytes [-Wframe-larger-than=] > > 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512") > > > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section > > mismatches > > > > Warnings: > > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > I'm still working on the fix, the same thing happens in mainline. > > > Warnings: > > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for > > NF_CT_PROTO_DCCP > > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for > > NF_CT_PROTO_UDPLITE > > 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change") > > > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches > > > > Errors: > > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > > redefined [-Werror] > > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > > redefined [-Werror] > > 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition") > > > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not > > satisfy its constraints: > > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler > > error: in extract_constrain_insn, at recog.c:2190 > > Warnings: > > b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig") > > > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for > > SCSI_DH > > ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change") > > > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches > > > > Errors: > > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option > > -mr10k-cache-barrier=store. Stop. > > 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc") > > > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches > > > > Warnings: > > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid > > for CPU_FREQ_STAT > > b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change") > > > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > > > Warnings: > > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of > > 'strncpy' discards 'const' qualifier from pointer target type > > [-Wdiscarded-qualifiers] > > 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy") > > > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches > > > > Warnings: > > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this > > function [-Wuninitialized] > > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this > > function [-Wuninitialized] > > 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().") > > > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not > > used [-Wunused-function] > > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not > > used [-Wunused-function] > > d92240d12a9c ("MIPS: ralink: Remove unused timer functions") > > > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not > > used [-Wunused-function] > > 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions") All now queued up in the stable trees, thanks. greg k-h
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Tue, Feb 28, 2017 at 02:31:51PM +0100, Arnd Bergmann wrote: > On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org bot wrote: > > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings > > A lot of fixes for these build problems have now landed in mainline, and > we could backport them as soon as they are considered stable enough. > If all of these make it into stable, we should have a clean build on MIPS and > ARM, and only the KASAN warnings remaining x86 and arm64. > > > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > > > Warnings: > > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than > > 1024 bytes [-Wframe-larger-than=] > > 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512") > > > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section > > mismatches > > > > Warnings: > > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is > > larger than 2048 bytes [-Wframe-larger-than=] > > I'm still working on the fix, the same thing happens in mainline. > > > Warnings: > > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for > > NF_CT_PROTO_DCCP > > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for > > NF_CT_PROTO_UDPLITE > > 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change") > > > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches > > > > Errors: > > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > > redefined [-Werror] > > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > > redefined [-Werror] > > 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition") > > > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not > > satisfy its constraints: > > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler > > error: in extract_constrain_insn, at recog.c:2190 > > Warnings: > > b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig") > > > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for > > SCSI_DH > > ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change") > > > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches > > > > Errors: > > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option > > -mr10k-cache-barrier=store. Stop. > > 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc") > > > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches > > > > Warnings: > > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid > > for CPU_FREQ_STAT > > b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change") > > > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > > > Warnings: > > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of > > 'strncpy' discards 'const' qualifier from pointer target type > > [-Wdiscarded-qualifiers] > > 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy") > > > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches > > > > Warnings: > > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this > > function [-Wuninitialized] > > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this > > function [-Wuninitialized] > > 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().") > > > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not > > used [-Wunused-function] > > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not > > used [-Wunused-function] > > d92240d12a9c ("MIPS: ralink: Remove unused timer functions") > > > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not > > used [-Wunused-function] > > 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions") All now queued up in the stable trees, thanks. greg k-h
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org botwrote: > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings A lot of fixes for these build problems have now landed in mainline, and we could backport them as soon as they are considered stable enough. If all of these make it into stable, we should have a clean build on MIPS and ARM, and only the KASAN warnings remaining x86 and arm64. > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > Warnings: > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than > 1024 bytes [-Wframe-larger-than=] 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512") > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section > mismatches > > Warnings: > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is > larger than 2048 bytes [-Wframe-larger-than=] I'm still working on the fix, the same thing happens in mainline. > Warnings: > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for > NF_CT_PROTO_DCCP > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for > NF_CT_PROTO_UDPLITE 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change") > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches > > Errors: > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > redefined [-Werror] > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > redefined [-Werror] 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition") > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not > satisfy its constraints: > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler > error: in extract_constrain_insn, at recog.c:2190 > Warnings: b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig") > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for > SCSI_DH ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change") > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches > > Errors: > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option > -mr10k-cache-barrier=store. Stop. 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc") > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches > > Warnings: > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid > for CPU_FREQ_STAT b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change") > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > Warnings: > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of > 'strncpy' discards 'const' qualifier from pointer target type > [-Wdiscarded-qualifiers] 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy") > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches > > Warnings: > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this > function [-Wuninitialized] > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this > function [-Wuninitialized] 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().") > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not > used [-Wunused-function] > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not > used [-Wunused-function] d92240d12a9c ("MIPS: ralink: Remove unused timer functions") > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not > used [-Wunused-function] 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions") Arnd
Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)
On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org bot wrote: > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings A lot of fixes for these build problems have now landed in mainline, and we could backport them as soon as they are considered stable enough. If all of these make it into stable, we should have a clean build on MIPS and ARM, and only the KASAN warnings remaining x86 and arm64. > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > Warnings: > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than > 1024 bytes [-Wframe-larger-than=] 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512") > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section > mismatches > > Warnings: > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is > larger than 2048 bytes [-Wframe-larger-than=] > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is > larger than 2048 bytes [-Wframe-larger-than=] I'm still working on the fix, the same thing happens in mainline. > Warnings: > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for > NF_CT_PROTO_DCCP > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for > NF_CT_PROTO_UDPLITE 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change") > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches > > Errors: > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > redefined [-Werror] > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" > redefined [-Werror] 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition") > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not > satisfy its constraints: > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler > error: in extract_constrain_insn, at recog.c:2190 > Warnings: b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig") > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for > SCSI_DH ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change") > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches > > Errors: > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option > -mr10k-cache-barrier=store. Stop. 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc") > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches > > Warnings: > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid > for CPU_FREQ_STAT b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change") > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches > > Warnings: > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of > 'strncpy' discards 'const' qualifier from pointer target type > [-Wdiscarded-qualifiers] 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy") > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches > > Warnings: > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this > function [-Wuninitialized] > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this > function [-Wuninitialized] 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().") > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not > used [-Wunused-function] > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not > used [-Wunused-function] d92240d12a9c ("MIPS: ralink: Remove unused timer functions") > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not > used [-Wunused-function] 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions") Arnd