Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751586AbcJJFCL (ORCPT ); Mon, 10 Oct 2016 01:02:11 -0400 Received: from ozlabs.org ([103.22.144.67]:37733 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750729AbcJJFCK (ORCPT ); Mon, 10 Oct 2016 01:02:10 -0400 From: Michael Ellerman To: Anton Blanchard , 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.org Subject: Re: perf TUI fails with "failed to process type: 64" In-Reply-To: <20161009121232.174915eb@kryten> References: <20161009121232.174915eb@kryten> User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Mon, 10 Oct 2016 16:02:07 +1100 Message-ID: <874m4k7q5s.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1657 Lines: 66 Anton Blanchard writes: > Hi, > > 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 ^ What's this? The address? If so it's wrong? > 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: ... > > 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? Seems likely. But I can't see why. AFAICS we have never emitted a size for those symbols: Old: $ nm --print-size build/vmlinux | grep -w system_call_relon_pSeries c000000000004c00 T system_call_relon_pSeries New: $ nm --print-size build/vmlinux | grep -w exc_virt_0x4c00_system_call c000000000004c00 T exc_virt_0x4c00_system_call It also doesn't look like we're emitting another symbol with the same address, which has caused confusion in the past: Old: c000000000004c00 T exc_virt_0x4c00_system_call c000000000004d00 T exc_virt_0x4d00_single_step New: c000000000004c00 T system_call_relon_pSeries c000000000004d00 T single_step_relon_pSeries So more digging required. cheers