Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3619389imd; Mon, 29 Oct 2018 09:46:00 -0700 (PDT) X-Google-Smtp-Source: AJdET5ftQPUe9zgzbXko0bLD1rMJtV6PwWYoD6C0mzy1wzVfryvQHRQajON6O/a+b3hxFv+Gfjwg X-Received: by 2002:a63:4952:: with SMTP id y18-v6mr14499554pgk.32.1540831560645; Mon, 29 Oct 2018 09:46:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540831560; cv=none; d=google.com; s=arc-20160816; b=PP1E0iAw7r2JDU3Jj1zpzfQH9rAMAHhZKUPwQ19L02ZmnnkTlsCoH1T0YpxSjRSFXS qZdg5h+RAMjWrGA1x0Ls/ZHYEjsxN9Qqf4acuvocQoMMkHfv4KHdVhp+8NLdnWunoJgp F2K64JGqx+Nx3DDo2LO/41dvgr6mcnQAGpnOOJBSzU0LMNkXicnZZHOsmlvhI/hex1EP 6MIHEbFTKSCfdBENGSiwemRVHM5M3JMDHQANcKcFvA4yua6Qz2MHpauZUjtvk16q8qpM xx7lFUnHS3l9DdzHGs8RSbrygqWZ1IoBU86KrQMhgC4VvZ80QugO9HHXkjSTe5zgGFk/ LaaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=1qHhjFLujOUK+2vmjbboZVuMFzL7yqG9KPUVIXe6d5A=; b=bbQNTBHzrHrEozKsi5yvlXerH2YRH1dQojWWIxy3uTCOpVcl9P9jiK/LBRB/9Z3NPK eJUXAnea+u/7Sh5mqgHkJXF1i1tKEENDlV8CjHWEKOQCIWMkyk/A9j+dkSW+hgYTbAA5 VJFifbihlNVi+zGDYqVHym6b1gqnHsQh+CyBDBYN1lSLpnYuM1QrOeJ/xd5qp4rvlSWC 4vzoAIVTIRtn+vPQOXkdED2zOSKQ0Adgqu70OKpk0FnjsrHo7LRryhsj7oa0KvN3zPzU MmhFr4SApTtB9yZMDBSqhzWD5VqWekCimhGXdNnYIvuHnAxZhlJhUDdhvUdheMVP9UZK HtUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=Sdnpcip+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c4-v6si18922666plo.69.2018.10.29.09.45.44; Mon, 29 Oct 2018 09:46:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@armlinux.org.uk header.s=pandora-2014 header.b=Sdnpcip+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727869AbeJ3BdJ (ORCPT + 99 others); Mon, 29 Oct 2018 21:33:09 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:39586 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727461AbeJ3BdJ (ORCPT ); Mon, 29 Oct 2018 21:33:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1qHhjFLujOUK+2vmjbboZVuMFzL7yqG9KPUVIXe6d5A=; b=Sdnpcip+ZWyQYYhPTNMEEBgXC BJUo9Hfd4MKA9lqWKr78+W/Him2MhKrFPkuCrZK9LJMPlHcAuehXVwIrdZybr009iJbI26xr8MoUF X6jXDDX7YrWN41vIezIHyXWJ5iCGa0CQ9AcYUCSYm+vYWyZZS9qxu0S0ODsA2nE+gNLBU=; Received: from n2100.armlinux.org.uk ([2002:4e20:1eda:1:214:fdff:fe10:4f86]:39006) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gHAda-0005X1-6Y; Mon, 29 Oct 2018 16:43:34 +0000 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.90_1) (envelope-from ) id 1gHAdX-0003ES-Bb; Mon, 29 Oct 2018 16:43:31 +0000 Date: Mon, 29 Oct 2018 16:43:29 +0000 From: Russell King - ARM Linux To: Mark Rutland Cc: "Wiebe, Wladislav (Nokia - DE/Ulm)" , "tony@atomide.com" , "akpm@linux-foundation.org" , "ebiederm@xmission.com" , "jrdr.linux@gmail.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] arm: mm: fault: check ADFSR in case of abort Message-ID: <20181029164329.GH30658@n2100.armlinux.org.uk> References: <20181029155435.prz2htt4ktte7pxb@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181029155435.prz2htt4ktte7pxb@lakrids.cambridge.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 29, 2018 at 03:54:36PM +0000, Mark Rutland wrote: > On Mon, Oct 29, 2018 at 02:20:51PM +0000, Wiebe, Wladislav (Nokia - DE/Ulm) wrote: > > When running into situations like: > > "Unhandled fault: synchronous external abort (0x210) at 0xXXX" > > or > > "Unhandled prefetch abort: synchronous external abort (0x210) at 0xXXX" > > it is useful to know the content of ADFSR (Auxiliary Data Fault Status > > Register) to indicate an ECC double-bit error in L1 or L2 cache. > > > > Refer to: > > Cortex-A15 Technical Reference Manual, Revision: r2p1 > > [6.4.8. Error Correction Code] > > > > Signed-off-by: Wladislav Wiebe > > --- > > arch/arm/mm/fault.c | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c > > index 3232afb6fdc0..5e240deb6ed6 100644 > > --- a/arch/arm/mm/fault.c > > +++ b/arch/arm/mm/fault.c > > @@ -547,6 +547,22 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *) > > fsr_info[nr].name = name; > > } > > > > +/* > > + * Check for ECC double-bit errors in Auxiliary Data Fault Status Register > > + */ > > +static void check_adfsr_for_ecc(void) > > +{ > > + u32 adfsr = 0; > > + > > + asm("mrc p15, 0, %0, c5, c1, 0" : "=r" (adfsr)); > > + > > + if (adfsr & (BIT(31) | BIT(23))) { > > + pr_alert("ADFSR status 0x%x indicates that an L1 or L2 cache\n" > > + "ECC double-bit error occurred at some time.\n", > > + adfsr); > > + } > > +} > > + > > /* > > * Dispatch a data abort to the relevant handler. > > */ > > @@ -559,6 +575,7 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs) > > if (!inf->fn(addr, fsr & ~FSR_LNX_PF, regs)) > > return; > > > > + check_adfsr_for_ecc(); > > pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n", > > inf->name, fsr, addr); > > show_pte(current->mm, addr); > > @@ -593,6 +610,7 @@ do_PrefetchAbort(unsigned long addr, unsigned int ifsr, struct pt_regs *regs) > > if (!inf->fn(addr, ifsr | FSR_LNX_PF, regs)) > > return; > > > > + check_adfsr_for_ecc(); > > pr_alert("Unhandled prefetch abort: %s (0x%03x) at 0x%08lx\n", > > inf->name, ifsr, addr); > > IIUC at this point the task is preemptible (and interruptible), It may be preemptable, but isn't necessarily so. It depends whether the called FSR specific function enabled interrupts or not. So, it would be better to read the ADFSR before calling the FSR specific function to guarantee that we read the values that correspond with _this_ fault. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up