[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Aug 2018 12:39:28 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Will Deacon <will.deacon@....com>,
Jingoo Han <jingoohan1@...il.com>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
libc-alpha@...rceware.org,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Russell King <linux@...linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Matt Sealey <neko@...uhatsu.net>, linux-pci@...r.kernel.org,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: framebuffer corruption due to overlapping stp instructions on
arm64
On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> while (1) {
> start = (unsigned)random() % (LEN + 1);
> end = (unsigned)random() % (LEN + 1);
> if (start > end)
> continue;
> for (i = start; i < end; i++)
> data[i] = val++;
> memcpy(map + start, data + start, end - start);
> if (memcmp(map, data, LEN)) {
It may be worth trying to do a memcmp(map+start, data+start, end-start)
here to see whether the hazard logic fails when the writes are unaligned
but the reads are not.
This problem may as well appear if you do byte writes and read longs
back (and I consider this a hardware problem on this specific board).
--
Catalin
Powered by blists - more mailing lists