linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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 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).