From patchwork Sun Sep 23 15:20:34 2018
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: John David Anglin <dave.anglin@bell.net>
X-Patchwork-Id: 10611765
Return-Path: <linux-parisc-owner@kernel.org>
Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org
 [172.30.200.125])
	by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 23E92913
	for <patchwork-linux-parisc@patchwork.kernel.org>;
 Sun, 23 Sep 2018 15:20:39 +0000 (UTC)
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])
	by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 102B729F19
	for <patchwork-linux-parisc@patchwork.kernel.org>;
 Sun, 23 Sep 2018 15:20:39 +0000 (UTC)
Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486)
	id 03B4629F21; Sun, 23 Sep 2018 15:20:39 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	pdx-wl-mail.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_HI,UNPARSEABLE_RELAY autolearn=ham version=3.3.1
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 54D2A29F19
	for <patchwork-linux-parisc@patchwork.kernel.org>;
 Sun, 23 Sep 2018 15:20:38 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726134AbeIWVS0 (ORCPT
        <rfc822;patchwork-linux-parisc@patchwork.kernel.org>);
        Sun, 23 Sep 2018 17:18:26 -0400
Received: from simcoe208srvr.owm.bell.net ([184.150.200.208]:44942 "EHLO
        torfep02.bell.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
        with ESMTP id S1726126AbeIWVSZ (ORCPT
        <rfc822;linux-parisc@vger.kernel.org>);
        Sun, 23 Sep 2018 17:18:25 -0400
Received: from bell.net torfep02 184.150.200.158 by torfep02.bell.net
          with ESMTP
          id <20180923152035.CVPH23720.torfep02.bell.net@torspm01.bell.net>
          for <linux-parisc@vger.kernel.org>;
          Sun, 23 Sep 2018 11:20:35 -0400
Received: from mx3210.localdomain ([70.53.62.196]) by torspm01.bell.net
          with ESMTP
          id <20180923152035.NSFR26298.torspm01.bell.net@mx3210.localdomain>;
          Sun, 23 Sep 2018 11:20:35 -0400
Received: by mx3210.localdomain (Postfix, from userid 1000)
        id CD0B92200F9; Sun, 23 Sep 2018 11:20:34 -0400 (EDT)
Date: Sun, 23 Sep 2018 11:20:34 -0400
From: John David Anglin <dave.anglin@bell.net>
To: linux-parisc <linux-parisc@vger.kernel.org>
Cc: Helge Deller <deller@gmx.de>,
        James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: [PATCH] parisc: Reorder TLB flush timing calculation
Message-ID: <20180923152033.GA15162@mx3210.localdomain>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Cloudmark-Analysis: v=2.2 cv=DZT4krlW c=1 sm=0 tr=0
 a=Zvhif4XNTjWcJyJCfFIh1A==:17 a=JBFolyDoGHsA:10 a=FBHGMhGWAAAA:8
 a=XQJuQiTDyKZMf2GkELYA:9 a=CHZoGKZZR-J5jGxT:21 a=ka119InlPXy5_zK5:21
 a=CjuIK1q_8ugA:10 a=TzAEYPCYjyV5UawoINEA:9 a=ONNS8QRKHyMA:10
 a=9gvnlMMaQFpL9xblJ6ne:22
Sender: linux-parisc-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-parisc.vger.kernel.org>
X-Mailing-List: linux-parisc@vger.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP

On boot (mostly reboot), my c8000 sometimes crashes after it prints the
TLB flush threshold.  The lockup is hard.  The front LED flashes red and
the box must be unplugged to reset the error.

I noticed that when the crash occurs the TLB flush threshold is about
one quarter what it is on a successful boot.  If I disabled the calculation,
the crash didn't occur.  There also seemed to be a timing dependency
affecting the crash.  I finally realized that the flush_tlb_all() timing
test runs just after the secondary CPUs are started.  There seems to be
a problem with running flush_tlb_all() too soon after the CPUs are started.

The timing for the range test always seemed okay.  So, I reversed the order
of the two timing tests and I haven't had a crash at this point so far.

I added a couple of information messages which I have left to help with
diagnosis if the problem should appear on another machine.


Signed-off-by: John David Anglin <dave.anglin@bell.net>

diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index e3b45546d589..3031c21f7c35 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -363,7 +375,7 @@ EXPORT_SYMBOL(flush_kernel_icache_range_asm);
 #define FLUSH_THRESHOLD 0x80000 /* 0.5MB */
 static unsigned long parisc_cache_flush_threshold __read_mostly = FLUSH_THRESHOLD;
 
-#define FLUSH_TLB_THRESHOLD (2*1024*1024) /* 2MB initial TLB threshold */
+#define FLUSH_TLB_THRESHOLD (512*1024) /* 0.5MB minimum TLB threshold */
 static unsigned long parisc_tlb_flush_threshold __read_mostly = FLUSH_TLB_THRESHOLD;
 
 void __init parisc_setup_cache_timing(void)
@@ -403,10 +415,6 @@ void __init parisc_setup_cache_timing(void)
 		goto set_tlb_threshold;
 	}
 
-	alltime = mfctl(16);
-	flush_tlb_all();
-	alltime = mfctl(16) - alltime;
-
 	size = 0;
 	start = (unsigned long) _text;
 	rangetime = mfctl(16);
@@ -417,13 +425,19 @@ void __init parisc_setup_cache_timing(void)
 	}
 	rangetime = mfctl(16) - rangetime;
 
-	printk(KERN_DEBUG "Whole TLB flush %lu cycles, flushing %lu bytes %lu cycles\n",
+	alltime = mfctl(16);
+	flush_tlb_all();
+	alltime = mfctl(16) - alltime;
+
+	printk(KERN_INFO "Whole TLB flush %lu cycles, Range flush %lu bytes %lu cycles\n",
 		alltime, size, rangetime);
 
-	threshold = PAGE_ALIGN(num_online_cpus() * size * alltime / rangetime);
+	threshold = PAGE_ALIGN((num_online_cpus() * size * alltime) / rangetime);
+	printk(KERN_INFO "Calculated TLB flush threshold %lu KiB\n",
+		threshold/1024);
 
 set_tlb_threshold:
-	if (threshold)
+	if (threshold > parisc_tlb_flush_threshold)
 		parisc_tlb_flush_threshold = threshold;
 	printk(KERN_INFO "TLB flush threshold set to %lu KiB\n",
 		parisc_tlb_flush_threshold/1024);
