From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Martin Hicks <mort@bork.org>
Cc: Scott Wood <scottwood@freescale.com>,
linuxppc-dev@lists.ozlabs.org, Anton Blanchard <anton@samba.org>
Subject: Re: Perf not resolving all symbols, showing 0x7ffffxxx
Date: Wed, 16 Oct 2013 13:42:08 -0500 [thread overview]
Message-ID: <1381948928.17841.38.camel@pasglop> (raw)
In-Reply-To: <CAJUS3Xm6-Mojvu6WkZNT+31oDazcx5HCr3n0asNqv3+uFbO0JQ@mail.gmail.com>
On Wed, 2013-10-16 at 11:05 -0400, Martin Hicks wrote:
> Actually, I was wrong, the mpc8379 is an e300c4.
>
> So it seems clear to me that we compile in the book3s code because
> this is an 83xx CPU part. I also see that Kconfig knows that I have
> an core-fsl-emb but we don't actually compile the PMU backend for it
> because there's no support for anything but e500.
>
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep PERF .config
> CONFIG_FSL_EMB_PERFMON=y
> CONFIG_PPC_PERF_CTRS=y
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_EVENTS=y
> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
> CONFIG_PPC_BOOK3S_32=y
> CONFIG_PPC_BOOK3S=y
>
> more below...
>
> On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
> >> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> >> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> >> > > >
> >> > > > 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.
>
> CONFIG_PPC_PERF_CTRS seems to give the mpc8379 some kind of basic
> performance measuring. Is this through dummy_perf() in
> arch/powerpc/kernel/pmc.c?
>
> >
> > Mort, can you see if just that change is enough to cause the problem ?
>
> It is not. The patch that does get IPs working again in my 3.11 tree
> is this one:
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index eeae308..9a3f572 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -122,10 +122,6 @@ void power_pmu_flush_branch_stack(void) {}
> static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
> #endif /* CONFIG_PPC32 */
>
> -static bool regs_use_siar(struct pt_regs *regs)
> -{
> - return !!regs->result;
> -}
Can you try instead just chaning regs_use_siar to return false always ?
Do that help ?
Cheers,
Ben.
> /*
> * Things that are specific to 64-bit implementations.
> @@ -1802,14 +1798,13 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
> */
> unsigned long perf_instruction_pointer(struct pt_regs *regs)
> {
> - bool use_siar = regs_use_siar(regs);
> -
> - if (use_siar && siar_valid(regs))
> - return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> - else if (use_siar)
> - return 0; // no valid instruction pointer
> - else
> + unsigned long mmcra = regs->dsisr;
> + if (TRAP(regs) != 0xf00)
> + return regs->nip;
> + if ((ppmu->flags & PPMU_NO_CONT_SAMPLING) &&
> + !(mmcra & MMCRA_SAMPLE_ENABLE))
> return regs->nip;
> + return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> }
>
> static bool pmc_overflow_power7(unsigned long val)
>
>
> mh
>
next prev parent reply other threads:[~2013-10-16 18:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 14:21 Perf not resolving all symbols, showing 0x7ffffxxx Martin Hicks
2013-10-15 13:59 ` Martin Hicks
2013-10-15 15:30 ` Benjamin Herrenschmidt
2013-10-15 18:44 ` Martin Hicks
2013-10-15 19:53 ` Benjamin Herrenschmidt
2013-10-15 20:22 ` Scott Wood
2013-10-15 20:39 ` Benjamin Herrenschmidt
2013-10-16 15:05 ` Martin Hicks
2013-10-16 18:42 ` Benjamin Herrenschmidt [this message]
2013-10-16 21:16 ` Martin Hicks
2013-10-16 23:01 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1381948928.17841.38.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=anton@samba.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mort@bork.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.