From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96243 invoked by alias); 23 Jun 2016 19:22:58 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 96232 invoked by uid 89); 23 Jun 2016 19:22:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:576C29E, H*i:sk:576C29E, H*MI:sk:576C29E X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 23 Jun 2016 19:22:47 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3897B80E4A; Thu, 23 Jun 2016 19:22:46 +0000 (UTC) Received: from [10.13.129.159] (dhcp129-159.rdu.redhat.com [10.13.129.159]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5NJMjQK031754; Thu, 23 Jun 2016 15:22:45 -0400 Subject: Re: exercising current aarch64 kprobe support with systemtap To: David Long , Pratyush Anand References: <8f40d0b9-5550-92f9-d1c5-8769f52304c0@redhat.com> <576B5501.1030106@linaro.org> <576C29E1.8060805@linaro.org> Cc: systemtap@sourceware.org, Mark Brown , Jeremy Linton , David Smith From: William Cohen Message-ID: <0a594132-796b-779d-b473-a06c0f3e8ae8@redhat.com> Date: Thu, 23 Jun 2016 19:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <576C29E1.8060805@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q2/txt/msg00282.txt.bz2 On 06/23/2016 02:26 PM, David Long wrote: > On 06/23/2016 11:49 AM, William Cohen wrote: >> On 06/22/2016 11:18 PM, David Long wrote: >>> On 06/22/2016 04:24 PM, William Cohen wrote: >>>> Hi all, >>>> >>>> When running the current systemtap checked out from the git repository >>>> and a locally built kernel with the kprobes64-v13 patches (the >>>> test_upstream_arm64_devel branch of >>>> https://github.com/pratyushanand/linux) on Fedora 23 machine one of >>>> the kprobes_onthefly.exp tests is causing the machine to get in a >>>> state that requires rebooting to fix. This can be triggered by running a >>>> portion of the systemtap tests with: >>>> >>>> make installcheck RUNTESTFLAGS="--debug systemtap.onthefly/kprobes_onthefly.exp" >>>> >>>> When it gets to the kprobes_onthefly - otf_stress_max_iter_5000 test the >>>> console starts spewing the following and needs to be rebooted: >>>> >>>> [23394.036860] Unexpected kernel single-step exception at EL1 >>>> [23394.042434] Unexpected kernel single-step exception at EL1 >>>> [23394.048008] Unexpected kernel single-step exception at EL1 >>>> [23394.053541] Unexpected kernel single-step exception at EL1 >>>> [23394.059053] Unexpected kernel single-step exception at EL1 >>>> [23394.064545] Unexpected kernel single-step exception at EL1 >>>> >>>> Sorry I don't have the start of the failure it scrolled off the screen very quickly. >>>> >>>> -Will >>>> >>>> >>> >>> I'll take a look and see what I can figure out. >>> >>> In the meantime I did just push a v14 branch. I'm doubtful that it will address the above problem even though it contains a few bug fixes. >>> >>> -dl >>> >> >> Hi Dave and Pratyush, >> >> I tried the kprobes64-v13 kernel and it also seems to work, so it lookw like the problem might be in the the >> test_upstream_arm64_devel branch of https://github.com/pratyushanand/linux . >> >> -Will >> > > I'm going to interpret that as meaning you know of no problem in the kprobes v14 patch that would give me pause to email it upstream. Do you disagree? > > -dl > Hi Dave, Yes, the problem only seems to be in that other kernel from https://github.com/pratyushanand/linux with the kprobe and uprobe patches, so the arm64 patches do not appear to be the problem. I don't know what is causing the problem maybe there is something going on with the porting of the patches to that kernel or the patches included in there (uprobes/kexec) in there. -Will