Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3890755imm; Mon, 6 Aug 2018 12:23:59 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcq9C1v8yPUk8fWmmovbWIPmZqn7YOZA86XREf3pbdTQMFb7ykKEufaxfX8Ay7NDetXKNCV X-Received: by 2002:a65:4d05:: with SMTP id i5-v6mr15581443pgt.58.1533583439200; Mon, 06 Aug 2018 12:23:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533583439; cv=none; d=google.com; s=arc-20160816; b=sglU39JgZpy0oDV6r7rH38XAgsm2sXZ1fQmTCXqgU18MFTS/Uuw6Vy4tSRoId3DEL8 wxCgtzxtFos82BuH3vHlqhfoFi+kg8fnin60KssqxoyH6/m8Feqq209qSt6d2XRmlBOb OeolBOgyXGmR22jNuyycIADsNh0J4EMhP+XcL4XjKqMoAdrbXCbWu/wHALg4IO70kLeF jmUvenmGsL+hH+nC8jpeqg3paGzTbbCEwZHx5VTfPlo07pnopfi/3/4glmfVNOqdpH/t cT3p2l1MSjHcRwhI0IoNCWLz6cCseppFgEtjqEqX6N5SM9U6/uVRSYoQ2dNDDiaBMMlR J/1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=rLwlpp9/YTxT3Hq7Ltf9qjHFhosyq9HwwslQLUZT9Ao=; b=KzJlbtAVLxPu0I2WhKW2PoO8/43Q7louSFObTp7/A88Bm3BnYz1jEGzFaHDXGM58Bo BQ70ocXZ+MY1ZnMZp4FaC2KImafmVdyVILuEPJviJX1L69jJDm3u4Ji5AGpWtRsaAY5V m7QqxXTgXzNFMylsJSSYs9HDqX1DRDJPT0PMBErawa+muhq2ya3PiWJWdmP1Ls41+VyW F2cWlRjtPJoVEQ16Kib3eqZYoHqbtTG8KELEZ3jM0w0nAoMHfZdn0SINOPDX7thrSmxc i7oZfjUDe9d1MOcjS/Q8i6Er6V/mE/myolAZDabdyZJNQAfc9bYFyIKGu6NwePdGnVJt 4cUA== ARC-Authentication-Results: i=1; mx.google.com; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h16-v6si14525037pgb.39.2018.08.06.12.23.28; Mon, 06 Aug 2018 12:23:59 -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; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732495AbeHFT3Y (ORCPT + 99 others); Mon, 6 Aug 2018 15:29:24 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39896 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726279AbeHFT3Y (ORCPT ); Mon, 6 Aug 2018 15:29:24 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7302540241C1; Mon, 6 Aug 2018 17:19:19 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 534D61C59E; Mon, 6 Aug 2018 17:19:19 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id w76HJJmQ015027; Mon, 6 Aug 2018 13:19:19 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id w76HJIcc015023; Mon, 6 Aug 2018 13:19:18 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Mon, 6 Aug 2018 13:19:18 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Catalin Marinas cc: Ard Biesheuvel , Robin Murphy , Thomas Petazzoni , Joao Pinto , linux-pci , Will Deacon , Russell King , Linux Kernel Mailing List , Matt Sealey , Jingoo Han , linux-arm-kernel Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64 In-Reply-To: <20180806171356.kk45vd7n5bdi6ka3@armageddon.cambridge.arm.com> Message-ID: References: <20180803094129.GB17798@arm.com> <99fff4fe-afa9-f12f-a518-472a9dd1c530@arm.com> <20180806171356.kk45vd7n5bdi6ka3@armageddon.cambridge.arm.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 06 Aug 2018 17:19:19 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 06 Aug 2018 17:19:19 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mpatocka@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 6 Aug 2018, Catalin Marinas wrote: > On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote: > > On 6 August 2018 at 14:42, Robin Murphy wrote: > > > On 06/08/18 11:25, Mikulas Patocka wrote: > > > [...] > > >>> > > >>> None of this explains why some transactions fail to make it across > > >>> entirely. The overlapping writes in question write the same data to > > >>> the memory locations that are covered by both, and so the ordering in > > >>> which the transactions are received should not affect the outcome. > > >> > > >> You're right that the corruption couldn't be explained just by reordering > > >> writes. My hypothesis is that the PCIe controller tries to disambiguate > > >> the overlapping writes, but the disambiguation logic was not tested and it > > >> is buggy. If there's a barrier between the overlapping writes, the PCIe > > >> controller won't see any overlapping writes, so it won't trigger the > > >> faulty disambiguation logic and it works. > > >> > > >> Could the ARM engineers look if there's some chicken bit in Cortex-A72 > > >> that could insert barriers between non-cached writes automatically? > > > > > > I don't think there is, and even if there was I imagine it would have a > > > pretty hideous effect on non-coherent DMA buffers and the various other > > > places in which we have Normal-NC mappings of actual system RAM. > > > > Looking at the A72 manual, there is one chicken bit that looks like it > > may be related: > > > > CPUACTLR_EL1 bit #50: > > > > 0 Enables store streaming on NC/GRE memory type. This is the reset value. > > 1 Disables store streaming on NC/GRE memory type. > > > > so putting something like > > > > mrs x0, S3_1_C15_C2_0 > > orr x0, x0, #(1 << 50) > > msr S3_1_C15_C2_0, x0 > > > > in __cpu_setup() would be worth a try. > > Note that access to this register may be disabled at EL3 by firmware > (ACTLR_EL3.CPUACTLR). > > FWIW, Mikulas' test seems to run fine on a ThunderX1 with AMD > FirePro W2100 (on /dev/fb1) I have the EDK EFI firmware sources (and I can load it from a SD card, so there's no risk of bricking the board), so I can insert the write into it, if you say where. Mikulas