On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:

On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:

quoted

On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:

quoted

On Tue, Oct 15, 2013 at 11:30 AM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

On Tue, 2013-10-15 at 09:59 -0400, Martin Hicks wrote:

quoted

I've tracked the start of the strange instruction pointers in 'perf
report' to a commit by Anton:

commit 75382aa72f06823db7312ad069c3bae2eb3f8548
Author: Anton Blanchard [off-list ref]
Date:   Tue Jun 26 01:01:36 2012 +0000

    powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs

I don't know enough about PPC to know what's going on, but reverting
the changes to perf_instruction_pointer() gets me reasonable 'perf
report' output with 3.11.

This is an e300 core right ? (603...). Do that have an SIAR at all
(Scott ?)

Yes, e300c3.

Ok so I have a hard time figuring out how that patch can make a
difference since for all I can see, there is no perf backend upstream
for e300 at all :-(

I must certainly be missing something ... Scott, can you have a look ?

e300c3 has a core-fsl-emb style performance monitor (though Linux
doesn't support it yet).  If a bug was bisected to a change in
core-book3s.c, then it's probably a coincidence due to moving code
around.

Mort, can you see if just that change is enough to cause the problem ?

------------------- arch/powerpc/include/asm/perf_event.h --------------------
index 5c16b89..0bb2372 100644

@@ -26,8 +26,13 @@
 #include <asm/ptrace.h>
 #include <asm/reg.h>
 
+/*
+ * Overload regs->result to specify whether we should use the MSR (result
+ * is zero) or the SIAR (result is non zero).
+ */
 #define perf_arch_fetch_caller_regs(regs, __ip)			\
 	do {							\
+		(regs)->result = 0;				\
 		(regs)->nip = __ip;				\
 		(regs)->gpr[1] = *(unsigned long *)__get_SP();	\
 		asm volatile("mfmsr %0" : "=r" ((regs)->msr));	\

Ben.