Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753629AbcKUG25 (ORCPT ); Mon, 21 Nov 2016 01:28:57 -0500 Received: from hr2.samba.org ([144.76.82.148]:24161 "EHLO hr2.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbcKUG2z (ORCPT ); Mon, 21 Nov 2016 01:28:55 -0500 Date: Mon, 21 Nov 2016 17:28:18 +1100 From: Anton Blanchard To: Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Nicholas Piggin , ravi.bangoria@linux.vnet.ibm.com, acme@redhat.com, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.orgp Subject: Re: perf TUI fails with "failed to process type: 64" Message-ID: <20161121172818.161639c2@kryten> In-Reply-To: <20161009121232.174915eb@kryten> References: <20161009121232.174915eb@kryten> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1166 Lines: 45 Hi, I forgot about the set of issues below. Michael had a suggested powerpc fix for 3, but it it would be nice to fix the perf bugs in 1 and 2. Anton -- > Updating to mainline as of last night, I started seeing the following > error when running the perf report TUI: > > 0x46068 [0x8]: failed to process type: 68 > > This event is just PERF_RECORD_FINISHED_ROUND: > > 0x46068 [0x8]: event: 68 > . > . ... raw event: size 8 bytes > . 0000: 44 00 00 00 00 00 08 00 > D....... > > 0x46068 [0x8]: PERF_RECORD_FINISHED_ROUND > > Which of course is not our error. It took me a while to find the real > culprit: > > 14c00-14c00 g exc_virt_0x4c00_system_call > > A zero length symbol, which __symbol__inc_addr_samples() barfs on: > > if (addr < sym->start || addr >= sym->end) { > ... > return -ERANGE; > > Seems like we have 3 bugs here: > > 1. Output the real source of the error instead of > PERF_RECORD_FINISHED_ROUND > > 2. Don't exit the TUI if we find a sample on a zero length symbol > > 3. Why do we have zero length symbols in the first place? Does the > recent ppc64 exception clean up have something to do with it? > > Anton