Hi Greg,

On Mon, 9 Jan 2012 07:42:59 -0800 Greg KH [off-list ref] wrote:

On Mon, Jan 09, 2012 at 05:20:16PM +1100, Stephen Rothwell wrote:

quoted

On Mon, 9 Jan 2012 16:59:50 +1100 Stephen Rothwell [off-list ref] wrote:

quoted

On Thu, 5 Jan 2012 16:04:48 -0800 Andrew Morton [off-list ref] wrote:

quoted

On Thu, 5 Jan 2012 19:04:05 +1100
Stephen Rothwell [off-list ref] wrote:

quoted

After merging the final tree, today's linux-next build (sparc64 defconfig)
failed like this:

In file included from include/trace/ftrace.h:567:0,
                 from include/trace/define_trace.h:86,
                 from include/trace/events/power.h:240,
                 from kernel/trace/power-traces.c:14:
include/trace/events/kmem.h: In function 'ftrace_test_probe_kmalloc':
include/trace/events/kmem.h:45:1: error: implicit declaration of function 'check_trace_callback_type_kmalloc' [-Werror=implicit-function-declaration]
include/trace/events/kmem.h: In function 'ftrace_test_probe_kmem_cache_alloc':

...

include/trace/events/kmem.h:267:1: error: implicit declaration of function 'check_trace_callback_type_mm_page_alloc_extfrag' [-Werror=implicit-function-declaration]
In file included from include/trace/ftrace.h:774:0,
                 from include/trace/define_trace.h:86,
                 from include/trace/events/power.h:240,
                 from kernel/trace/power-traces.c:14:
include/trace/events/kmem.h: In function 'perf_test_probe_mm_page_pcpu_drain':
include/trace/events/kmem.h:256:1: error: implicit declaration of function 'check_trace_callback_type_mm_page_pcpu_drain' [-Werror=implicit-function-declaration]

I have no idea what has gone wrong here, but I did not get this error
yesterday.  The only thing that touched include/trace/events/kmem.h is
patch "mm-tracepoint: rename page-free events" from the akpm tree, but
that was there yesterday as well and doesn't look suspicious.

Yes, it's not due to anything in the akpm tree.  Tracing stuff blew up.

quoted

I just have to leave things broken for today in the hope that someone
figures something out.  This does not affect my X86_64 allmodconfig build
or my PowerPC builds (including an allyesconfig build).

It fails with sparc64 defconfig but succeeds with sparc64 allmodconfig.
Some config-dependent thing.  3.2 is OK, so it's something in -next.

It could be that some far-off sparc64 Kconfig change is newly
triggering this.  

I suppose I could get off my ass and actually work out why it broke,
but the tracing code is too icky.

This failure is now in Linus' tree.  I am not sure when it got there.

Bisected down to:

8a25a2fd126c621f44f3aeaef80d51f00fc11639 is the first bad commit
commit 8a25a2fd126c621f44f3aeaef80d51f00fc11639
Author: Kay Sievers [off-list ref]
Date:   Wed Dec 21 14:29:42 2011 -0800

    cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem

How is this triggering this build problem?  I didn't see this happen
before, and it wasn't showing up in linux-next in the past, right?

I think this error showed up the first time that the sysdev removal stuff
was included in linux-next i.e. after the other errors/warnings had been
dealt with.

This patch has nothing to to with tracing, perhaps it is an #include
file problem?  Or is the build error a different one (remember the
-Werror problem in linux-next that I fixed up for PPC?)

confused,

The tracing code is obscure and I suspect that there may be some ordering
issue in there.  What seems to have triggered this is the include of
device.h instead of sysdev.h in cpu.h.  This has caused a whole lot more
tracepoints(?) to be defined.

So it is a side effect and needs the tracing guys to track it down :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/