From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6342C43613 for ; Fri, 21 Jun 2019 16:06:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7CDB320665 for ; Fri, 21 Jun 2019 16:06:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jsf1NorG"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gerhold.net header.i=@gerhold.net header.b="gDPTsCSA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CDB320665 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gerhold.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=sWBRT5xc679FT7iovwq14m6IkP5w5uFqWUuS2uE6a2I=; b=jsf1NorG9+tBIM FNhmoUxCqzk1oq4nTe55CM2PoHuHvzANU0KPudhD9g127BhCjNTPqMbX/XNW4crVP1OHFI01/Rjc7 /gKXHDIV0mEqBogDZrkALk3ehH1sqcBa6V4/o0SVZLGuNjiSgTz/gmzMa9hVkT40Lv5dOPsc3qkNH QLqtE9tLgC04FE1ZaorkOqOE8LI2OXsd4Qy2pvnvtzrxYxAzkQi9TDv49yOVM9g0x3RBzMvnJczwC bBASOVEu2twjyIlpN/w0SaBcxK9Ez2s+LWYLydyyb/kLO2jVlyLh+E9x+MsMXb0ORiKH7NLBHtZO3 qph+zRVJIGzSnrn9pKyg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1heM3z-0001sp-Pa; Fri, 21 Jun 2019 16:06:55 +0000 Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::9]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1heM3w-0001re-38 for linux-arm-kernel@lists.infradead.org; Fri, 21 Jun 2019 16:06:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1561133207; s=strato-dkim-0002; d=gerhold.net; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=Emdotc5KZs0nYoiDHIIYAIdqYH7BCst4xsvTGCscKW0=; b=gDPTsCSAec7z5agnWusOZSu6Ya7PWyxyoeBmihfFoZMxF5WJ0lzcqcDN+AiAbL+6qI 2tX5u1aF7qbU8rmXQIk6EA9gt8iIuHA1K5azu+wsyj972xaBMCdgYPB0Od8Idk0O9wXO hc2Ik71ZwvfCv4yfz32U8ggcSH0a7P0My/MwnVbHtBPiAkbtCVF+eMCsVwBpH2nNQRz/ pvMJMz7wDAgC+kUYfYwMtqaZUaT2yPpi47A5hLafrM13mYQ0McblAHwZ5fLmzpUHetTU gqP5T+kfxLzphwHZcct03PYejOm68yxDsXQgUO6DPX9jZ4eUr2g8oH+HQJ7iZ0x9pgaN OaZQ== X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u26zEodhPgRDZ8b5Ic/FbYo=" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 44.24 DYNA|AUTH) with ESMTPSA id m0a13fv5LG6gGTs (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 21 Jun 2019 18:06:42 +0200 (CEST) Date: Fri, 21 Jun 2019 18:06:31 +0200 From: Stephan Gerhold To: Mathieu Poirier , Suzuki K Poulose , Sudeep Holla Subject: Re: Coresight causes synchronous external abort on msm8916 Message-ID: <20190621160631.GA34922@gerhold.net> References: <20190618202623.GA53651@gerhold.net> <20190619183904.GB937@gerhold.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190621_090652_739319_B513ADD7 X-CRM114-Status: GOOD ( 39.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Brown , Sai Prakash Ranjan , Andy Gross , linux-arm-kernel , linux-arm-msm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, Thanks for all your replies! On Wed, Jun 19, 2019 at 02:16:38PM -0600, Mathieu Poirier wrote: > On Wed, 19 Jun 2019 at 12:39, Stephan Gerhold wrote: > > > > Hi, > > > > On Wed, Jun 19, 2019 at 09:49:03AM +0100, Suzuki K Poulose wrote: > > > Hi Stephan, > > > > > > On 18/06/2019 21:26, Stephan Gerhold wrote: > > > > Hi, > > > > > > > > I'm trying to run mainline Linux on a smartphone with MSM8916 SoC. > > > > It works surprisingly well, but the coresight devices seem to cause the > > > > following crash shortly after userspace starts: > > > > > > > > Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP > > > > > > ... > > > > > > > > > > > > > > In this case I'm using a simple device tree similar to apq8016-sbc, > > > > but it also happens using something as simple as msm8916-mtp.dts > > > > on this particular device. > > > > (Attached: dmesg log with msm8916-mtp.dts and arm64 defconfig) > > > > > > > > I can avoid the crash and boot without any further problems by disabling > > > > every coresight device defined in msm8916.dtsi, e.g.: > > > > > > > > tpiu@820000 { status = "disabled"; }; > > > > > > ... > > > > > > > > > > > I don't have any use for coresight at the moment, > > > > but it seems somewhat odd to put this in the device specific dts. > > > > > > > > Any idea what could be causing this crash? > > > > > > This is mostly due to the missing power domain support. The CoreSight > > > components are usually in a debug power domain. So unless that is turned on, > > > (either by specifying proper power domain ids for power management protocol > > > supported by the firmware OR via other hacks - e.g, connecting a DS-5 to > > > keep the debug power domain turned on , this works on Juno -). > > > > Interesting, thanks a lot! > > > > In this case I'm wondering how it works on the Dragonboard 410c. > > There can be two problems: > > 1) CPUidle is enabled on your platform and as I pointed out before, > that won't work. There are patches circulating[1] to fix that problem > but it still needs a little bit of work. I tried disabling cpuidle (see [1]), but unfortunately it did not help. [1]: https://lore.kernel.org/linux-arm-msm/20190619173743.GA937@gerhold.net/ > > 2) As Suzuki pointed out the debug power domain may not be enabled by > default on your platform, something I would understand if it is a > production device. There is nothing I can do on that front. Indeed, this is a production device. The downstream (production) kernel does not seem to have coresight enabled, so it is very well possible that the debug power domain is not enabled by the firmware. > > [1]. https://www.spinics.net/lists/arm-kernel/msg735707.html > > > Does it enable these power domains in the firmware? > > (Assuming it boots without this error...) > > The debug power domain is enabled by default on the 410c and the board > boots without error. Good to know, thank you! > > > > > If coresight is not working properly on all/most msm8916 devices, > > shouldn't coresight be disabled by default in msm8916.dtsi? > > It is in the defconfig for arm64, as such it shouldn't bother you. Indeed, I already have CONFIG_CORESIGHT disabled. At the moment, I'm using arm64 defconfig as-is, with no modifications. So the error happens in the AMBA bus code even when CONFIG_CORESIGHT is disabled, as Suzuki suspected [2]. [2]: https://lore.kernel.org/linux-arm-msm/6bb74dcc-62e4-5310-5884-9c4b82ce5be9@arm.com/ > > > At least until those power domains can be set up by the kernel. > > > > If this is a device-specific issue, what would be an acceptable solution > > for mainline? > > Can I turn on these power domains from the kernel? > > Yes, if you have the SoC's TRM. I guess "TRM" refers to Technical Reference Manual? Unfortunately, I don't have access to any documentation that is not publicly available on the Internet. > > > Or is it fine to disable coresight for this device with the snippet above? > > > > I'm not actually trying to use coresight, I just want the device to boot :) > > And since I am considering submitting my device tree for inclusion in > > mainline, I want to ask in advance how I should tackle this problem. > > Simply don't enable coresight in the kernel config if the code isn't > mature enough to properly handle the relevant power domains using the > PM runtime API. The error occurs without CONFIG_CORESIGHT, and I believe there is no way to disable CONFIG_AMBA (it is selected by CONFIG_ARM64 and included in arm64 defconfig). So, assuming it is the debug power domain, I believe I can make the device boot successfully by either: (a) Turning on the debug power domain: It seems like the kernel cannot do this on msm8916 at the moment(?) (msm8916.dtsi does not declare any power domain in the coresight device tree nodes) I cannot modify the firmware of this device, so I'm afraid I have absolutely no idea how to turn it on. :/ (b) Preventing the crash: Is there some way to: (1) Add a check in the AMBA bus code to verify if the power domain is actually turned on? or (2) Recover from the "synchronous external abort" and continue booting after printing an error/warning? (At the moment, userspace seems to continue for a while, but stops working at some point after the error...) Otherwise, there is still the option to prevent the AMBA bus code from running by disabling the affected device tree nodes. That's what the debug@850000 { status = "disabled"; }; ... snippet from my first mail [3] does, and it is the only way to make the kernel boot successfully at the moment. It wouldn't affect any other device if placed in the DTS for my device (i.e. *not* in the shared msm8916.dtsi). What do you think? Stephan [3]: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel