Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3281085imm; Mon, 6 Aug 2018 01:46:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfNCs6khxM8Ay8iGMWpmwKYhbWHX3a5GTvYt/KAgWMCuDwNdNmMq4OY72LAiSWeDUA8InwP X-Received: by 2002:a62:c288:: with SMTP id w8-v6mr15947015pfk.92.1533545172511; Mon, 06 Aug 2018 01:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533545172; cv=none; d=google.com; s=arc-20160816; b=ndeRZkjnDLrrl9mk68UAi7rHsv0mT8LxVs+24QAj2uithYNRMzkMqWMgdbhg5mQsKt vK7JHvfmSBi8V4RVQtMuSwXO4NQbqrKFsNEeKo9KhG2i6AT3oQpgcwBoq/cwhOKBox73 Z/iNGLgND8Y3DX4NRCrOg3t6vAwHGhoy5ECz/S293FuFuHgnqOC0NxSXGd10pzulgwhz oy6oYl5eufjXkr1lk9+HzyCF3UGHsmljduUNGnnVb18jusaKAoCqQ1EBcMIhWgQTzYiq HVEvpwo4adQkH97Dh41QFdp4mkVG2kFVM4VNd711fWA9TojuQKMYYhX1Wmd+tmElBdkA RFFw== 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:arc-authentication-results; bh=rK3VB6CFYFEk4MAPVX9S9vxJfyJ3x5HaXDy90usRWJA=; b=uJRg412ryOV63NdlnFHSsC2gDFPB2Nvyb0q9AhK8F3/q+3TNSTeHKvYBqvIMw5DE/X rLV6qg0QEQncvkK1+YgAYP8vm/dGlVM8z/dER+k0rp0F6PZYEeFvtBJKJtt+W8DUlre4 uG7COG0thAqFw5R45qdOce3C/L5qFE900ftEml+33BQ7z+szSmha316YN1sIDr+3xMRI J8QAGUN8uXkNtiijeNqDkhwcRXYcd96j/oWhuxH0BW+5ryB3vkBoCXMvbnyxBGBThTWO v7qN69hg8pfSi987WgWR2+u+6OlNtkqvDllwDHlDu6uNvhYA9g5MKZdP5WmrkAdxjJMe N19g== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 65-v6si12959995pfe.49.2018.08.06.01.45.57; Mon, 06 Aug 2018 01:46:12 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727102AbeHFKw4 (ORCPT + 99 others); Mon, 6 Aug 2018 06:52:56 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:59040 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725951AbeHFKwz (ORCPT ); Mon, 6 Aug 2018 06:52:55 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 6116C805FA; Mon, 6 Aug 2018 10:44:53 +0200 (CEST) Date: Mon, 6 Aug 2018 10:44:51 +0200 From: Pavel Machek To: Ramana Radhakrishnan Cc: Andrew Pinski , Mikulas Patocka , Catalin Marinas , Will Deacon , Russell King , Thomas Petazzoni , linux-arm-kernel , LKML , GNU C Library Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64 Message-ID: <20180806084451.GB19523@amd> References: <20180805213615.GA1862@amd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: 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 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon 2018-08-06 09:04:33, Ramana Radhakrishnan wrote: > On Sun, Aug 5, 2018 at 10:36 PM, Pavel Machek wrote: > > Hi! > > > >> > I tried to use a PCIe graphics card on the MacchiatoBIN board and I = hit a > >> > strange problem. > >> > > >> > When I use the links browser in graphics mode on the framebuffer, I = get > >> > occasional pixel corruption. Links does memcpy, memset and 4-byte wr= ites > >> > on the framebuffer - nothing else. > >> > > >> > I found out that the pixel corruption is caused by overlapping unali= gned > >> > stp instructions inside memcpy. In order to avoid branching, the arm= 64 > >> > memcpy implementation may write the same destination twice with diff= erent > >> > alignment. If I put "dmb sy" between the overlapping stp instruction= s, the > >> > pixel corruption goes away. > >> > > >> > This seems like a hardware bug. Is it a known errata? Do you have any > >> > workarounds for it? > >> > >> Yes fix Links not to use memcpy on the framebuffer. > >> It is undefined behavior to use device memory with memcpy. > > > > No, I don't think so. Why do you think so? >=20 > It is undefined behaviour in the architecture. Why do you think so? Pointer to documentation would be helpful. Normal access is used for mmapped areas, and I don't think we want to change that. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAltoCoMACgkQMOfwapXb+vLMhgCfY8CsLEMJdYhoRujXldzCqFLp 0GgAoI/Pf0nhwq9LnE7FhRGpwabQZBQI =Wa6e -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW--