From patchwork Wed Oct 16 21:16:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Hicks X-Patchwork-Id: 284030 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [IPv6:::1]) by ozlabs.org (Postfix) with ESMTP id 11AD92C03F4 for ; Thu, 17 Oct 2013 08:17:12 +1100 (EST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 126C42C0199 for ; Thu, 17 Oct 2013 08:16:45 +1100 (EST) Received: by mail-ie0-f178.google.com with SMTP id to1so3225989ieb.9 for ; Wed, 16 Oct 2013 14:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pj8Oy8WAA8rLMr/2Ys+RAdHZANRUPpOt7NHno8dp2Cw=; b=su1aThrvF83ca+I1QZK7ekY9HfLl8gFOBoM9tx07GzR6+5zVKUBuqKFFOttqIT33XR SMw8HiX7QkJoQ82L7BwzooBDF+ZJlAs0XxqW7uZTu0uS2F68wUVyM/ydaNLWVdBjUjDM a2C7XHG3WL68ufUH8kU81rgdjciCd2to5Q7PuXbtqCj7EUoXfYod/w2nv8DP+gKG5Mz/ Z2FTrXREQ2bwsaBgqLcS/DrHNT0xmZ78p3HiCr/lPMADcSgIVXep/A69YeRFwAKbrWY6 mGD6f0u4nFB+f74LB+0rpkZcbET7r3tI1QaM0RaO06ea/Dskp9AEz5T9BKmm3aPu/MSi /gaQ== MIME-Version: 1.0 X-Received: by 10.50.67.107 with SMTP id m11mr23653673igt.11.1381958202694; Wed, 16 Oct 2013 14:16:42 -0700 (PDT) Received: by 10.64.27.196 with HTTP; Wed, 16 Oct 2013 14:16:42 -0700 (PDT) In-Reply-To: <1381948928.17841.38.camel@pasglop> References: <1381851009.17841.14.camel@pasglop> <1381866837.17841.21.camel@pasglop> <1381868527.7979.713.camel@snotra.buserror.net> <1381869590.17841.23.camel@pasglop> <1381948928.17841.38.camel@pasglop> Date: Wed, 16 Oct 2013 17:16:42 -0400 X-Google-Sender-Auth: -Qn2g6_Xoz12mVoAIGCyvHSgZXo Message-ID: Subject: Re: Perf not resolving all symbols, showing 0x7ffffxxx From: Martin Hicks To: Benjamin Herrenschmidt Cc: Scott Wood , linuxppc-dev@lists.ozlabs.org, Anton Blanchard X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.16rc2 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Oct 16, 2013 at 2:42 PM, Benjamin Herrenschmidt wrote: > 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 >> 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 ? > That does fix the problem. v3.11 with the following: /* mh diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c index eeae308..e91cf67 100644 --- a/arch/powerpc/perf/core-book3s.c +++ b/arch/powerpc/perf/core-book3s.c @@ -124,7 +124,7 @@ static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {} static bool regs_use_siar(struct pt_regs *regs) { - return !!regs->result; + return 0; //!!regs->result; }