From patchwork Tue Nov 24 17:00:20 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Helge Deller X-Patchwork-Id: 7692221 Return-Path: X-Original-To: patchwork-linux-parisc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B74B19F1D3 for ; Tue, 24 Nov 2015 17:01:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id DA332207E1 for ; Tue, 24 Nov 2015 17:01:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E46B6207DF for ; Tue, 24 Nov 2015 17:01:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754139AbbKXRAj (ORCPT ); Tue, 24 Nov 2015 12:00:39 -0500 Received: from mout.gmx.net ([212.227.15.15]:56652 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753695AbbKXRAh (ORCPT ); Tue, 24 Nov 2015 12:00:37 -0500 Received: from p100.box ([92.203.1.112]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MSv6D-1ZrkJI2OP7-00RtpD; Tue, 24 Nov 2015 18:00:25 +0100 Date: Tue, 24 Nov 2015 18:00:20 +0100 From: Helge Deller To: Mikulas Patocka , Linus Torvalds , linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org, James Bottomley , John David Anglin Subject: Re: [GIT PULL] parisc huge page support for v4.4 Message-ID: <20151124170020.GA13198@p100.box> References: <20151122115153.GA28471@p100.box> <5654892D.1030707@gmx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:9qn/BaXuIsN4it4mo/lq+oP+JOabxdCQa6R2qyZRsDUurZH7+hF c6nB+aEmOPCeNvuPKvraiyy3wPdP4as1Vpj7Tjqnv2kaQbUI7XOS40+SPQHPzk+R2oT/Dlq BHUG3eDerG6BEm8vxsFUq2A6kL9h4d1hKZjCRO1ErnTYqSTQEkapFbwLnk0e52Z/pf7zzap sHSeIgfL0dgxqbqkXYJTw== X-UI-Out-Filterresults: notjunk:1; V01:K0:4zoQbb//K0s=:nPEk0J9Ov9y9XBltgUtcA3 yHMH3YS2L5ejL9QU+oYAFzkNj+lD+VNHQguXz+woiCxkUdBbWZbR8jhTGxumgyW3bgBZjUBO8 tw4W9Cpa5Z6K4G2wfCnN43gXZzyUMKCS6P2EMb/qk+jJbwYLNk6trDd3YgQvEjQx0AFypDpgJ 2qA8/TYuB/RvIdiM8dZ6QpN5ONPl2nvcZGEipdSPjOw41AIAEIZIvRkIPL5RkpRpZMRInC+f/ e7AYOUwIR7tteNY6LFMEYfHyN6u94wSW7sMkmrfQqlETgFmva4ViV7eDZBstZ0xAxgzl99HEm hXID6DxZL2E+yI2Fs65K1PAJL88RvMd5R/AqGt3ipbAIITIUXqvWnwPwknbqhLLbV1CHklduQ C6jH4Un3k4RbKZ3gq0V1DqUNaUZ8Xn3Bqqji2ZwVvS4tSzz99Rmw+w5SRk5i+AZCJKw7ZVi4d ToztxMa6SxRmrcGMtijUbOHuppuXERyl3PApPMlpDrrIjrUwxaPtTA8UaF1YcLanok6j3Nzu+ c0kyMOF7WlkJWYJzFdabORknah00P6VSQYkhpB6TRFIGu0+p+jJ6XLi8HH7ygOFetDIeTTqkj pJKjMo4cTskSWVIPEh/59cJtc/e7tEOcXSzT5sR8KJh7ycoBFPeXW8dE6wQ9itnjRLfMT/2qN 3sVEnqDyeO3NOiFGdYFqPtauUpFMHjk9hna7PfW2egJ1qdp71dki1Zb2vUB4d8aEqOpvR6DEJ 3UfgZQHxNDmLdaxP+1D5l8oa4t3L7R6esiHscP2fYAXsFMibC0rBWbIj7FU= Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP * Mikulas Patocka : > > > On Tue, 24 Nov 2015, Helge Deller wrote: > > > > Hi > > > > > > Since the kernel 4.4-rc2 I'm getting frequent boot failures on PA-RISC. > > > When I revert this patchset, the crashes are gone. > > > > > [ 3.296666] CPU(s): 4 out of 4 PA8900 (Shortfin) at 1000.000000 MHz online > > > > Hi Mikulas, > > > > Yes, I've seen this as well. > > It affects only the PA8900 CPUs, while all PA8500-PA8700 machines seem to work fine. > > I do have a temporary 3-line patch to avoid the crashes which I'll push to my tree shortly. > > I'm still investigating why it only affects the PA8900 CPUs, but I assume > > it's related to the cache aliasing of those CPUs. > > I'll keep you updated. > > > > Helge > > The PA-RISC specification doesn't allow aliasing on non-equaivalent > addresses. Can the kernel map a piece of kernel data to other virtual > address? If yes, we can't use big pages to map kernel data. Can you please try the two patches below? The first one disables mapping kernel text/data on huge pages on PA8800/PA8900 CPUs. Patch works for me on my Mako PA8800. Independend of my huge page patch the second patch disables the tlb flush optimization we added earlier. It seems calling flush_tlb_all() doesn't reliably flushes tlbs on all CPUs so it's better to fall back to the loop implementation. Helge --- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c index 1b366c4..958b7f36 100644 --- a/arch/parisc/mm/init.c +++ b/arch/parisc/mm/init.c @@ -475,19 +475,22 @@ static void __init map_pages(unsigned long start_vaddr, pte = __mk_pte(address, pgprot); else if (parisc_text_address(vaddr)) { pte = __mk_pte(address, PAGE_KERNEL_EXEC); - if (address >= ro_start && address < kernel_end) + if (address >= ro_start && address < kernel_end + && !parisc_requires_coherency()) pte = pte_mkhuge(pte); } else #if defined(CONFIG_PARISC_PAGE_SIZE_4KB) if (address >= ro_start && address < ro_end) { pte = __mk_pte(address, PAGE_KERNEL_EXEC); - pte = pte_mkhuge(pte); + if (!parisc_requires_coherency()) + pte = pte_mkhuge(pte); } else #endif { pte = __mk_pte(address, pgprot); - if (address >= ro_start && address < kernel_end) + if (address >= ro_start && address < kernel_end + && !parisc_requires_coherency()) pte = pte_mkhuge(pte); } diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c index cda6dbb..80ced95 100644 --- a/arch/parisc/kernel/cache.c +++ b/arch/parisc/kernel/cache.c @@ -445,7 +445,7 @@ int __flush_tlb_range(unsigned long sid, unsigned long start, unsigned long flags, size; size = (end - start); - if (size >= parisc_tlb_flush_threshold) { + if (0 && size >= parisc_tlb_flush_threshold) { flush_tlb_all(); return 1; }