From: Mikulas Patocka <mpatocka@redhat.com>
To: Andrew Pinski <pinskia@gmail.com>
Cc: Richard Earnshaw <Richard.Earnshaw@arm.com>,
ard.biesheuvel@linaro.org,
Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
Florian Weimer <fweimer@redhat.com>,
thomas.petazzoni@free-electrons.com,
GNU C Library <libc-alpha@sourceware.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux@armlinux.org.uk, LKML <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
Date: Sat, 4 Aug 2018 07:04:13 -0400 (EDT) [thread overview]
Message-ID: <alpine.LRH.2.02.1808040611070.23762@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <CA+=Sn1=6F-fGLmXE0VqQHTqTCUKUT=Fz29mMT7349SPFisbZ9A@mail.gmail.com>
On Fri, 3 Aug 2018, Andrew Pinski wrote:
> On Fri, Aug 3, 2018 at 5:58 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> >
> >
> > On Fri, 3 Aug 2018, Richard Earnshaw (lists) wrote:
> >
> > > Whoa, hold on.
> > >
> > > Memcpy should never be used on device memory. Period. Memcpy doesn't
> > > know anything about what size of access is needed for accessing a device.
> > >
> > > But why is the buffer in device memory rather than some other form of
> > > uncached memory?
> > >
> > > If you change memcpy to deal with an aspect of the system hardware,
> > > you'll end up hosing performance EVERYWHERE. DON'T DO IT!
> >
> > memcpy in glibc uses ifunc selection and it already has optimized variants
> > for Falkor and Thunder-X. You can add just another variant for Armada-8040
> > that works around this bug and you won't be harming anyone but users of
> > Armada-8040.
>
> Except it is not a bug in the ARMADA at all. It is a bug in thinking
> memcpy will work on non-DRAM memory.
There's plenty of memcpy's in the graphics stack. No one will be rewriting
all the graphics drivers because of tiny market share that ARM has in
desktop computers. So if you refuse to fix things and blame everyone else,
you can as well announce that you don't want to have PCIe graphics on ARM
at all.
> Can you run the test program on x86 using the similar framebuffer
> setup? Does doing two writes (one aligned and one unaligned but
> overlapping with previous one) cause the same issue? I suspect it
> does, then using memcpy for frame buffers is wrong.
>
> Thanks,
> Andrew
Overlapping unaligned writes work on x86 - they have to, because of
backward compatibility.
8086, 80286 and 80386 didn't have any cache at all.
80486 and Pentium had cache, but when the CPU was reading some data from
memory, the motherboard could disable cacheability for this data by a
special pin. Software didn't have to do any explicit cache management -
programs for 80386 that expected that there's no cache worked flawlessly
on 80486 and Pentium.
Pentium Pro had memory type range registers that determine cacheability of
various memory regions (so that it could allocate a cache line on write
without having to query the motherboard if the particular region of memory
is cacheable) - but the MTRRs were set by BIOS and the software didn't
have to care about them at all - an 80386 operating system that had no
idea of cacheability would still work on Pentium Pro.
MTRRs could also set a write-combining mode on a region of memory - but
again, this is completely transparent to the software (the write combining
buffers are flushed when accessing an I/O port or uncacheable memory) - so
that an accelerated graphics driver written for Pentium that had no idea
of write-combining would still work on Pentium Pro with write combining
enabled.
Mikulas
next prev parent reply other threads:[~2018-08-04 11:04 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-02 19:31 framebuffer corruption due to overlapping stp instructions on arm64 Mikulas Patocka
[not found] ` <CAHCPf3tFGqkYEcWNN4LaWThw_rVqT316pzLv6T7RfxwO-eZ0EA@mail.gmail.com>
2018-08-03 6:35 ` Mikulas Patocka
2018-08-03 7:16 ` Ard Biesheuvel
2018-08-03 9:41 ` Will Deacon
2018-08-03 17:09 ` Mikulas Patocka
2018-08-03 17:32 ` Sinan Kaya
2018-08-03 17:33 ` Ard Biesheuvel
2018-08-03 18:25 ` Mikulas Patocka
2018-08-03 20:44 ` Matt Sealey
2018-08-03 21:20 ` Ard Biesheuvel
2018-08-06 10:25 ` Mikulas Patocka
2018-08-06 12:42 ` Robin Murphy
2018-08-06 12:53 ` Ard Biesheuvel
2018-08-06 13:41 ` Marcin Wojtas
2018-08-06 13:48 ` Ard Biesheuvel
2018-08-06 14:07 ` Marcin Wojtas
2018-08-06 14:13 ` Mikulas Patocka
2018-08-06 15:47 ` Ard Biesheuvel
2018-08-06 17:09 ` Mikulas Patocka
2018-08-06 17:21 ` Ard Biesheuvel
2018-08-06 19:54 ` Mikulas Patocka
2018-08-06 20:11 ` Ard Biesheuvel
2018-08-06 20:31 ` Mikulas Patocka
2018-08-07 16:40 ` Marcin Wojtas
2018-08-07 17:39 ` Mikulas Patocka
2018-08-07 18:07 ` Ard Biesheuvel
2018-08-07 18:17 ` Mikulas Patocka
[not found] ` <CAPv3WKcKoEe=Qysp6Oac2C=G9bUhUQf1twSRCY+_qJ6XEC-iag@mail.gmail.com>
2018-08-08 14:10 ` Mikulas Patocka
2018-08-06 17:13 ` Catalin Marinas
2018-08-06 17:19 ` Mikulas Patocka
2018-08-08 18:31 ` Mikulas Patocka
2018-08-04 13:29 ` Mikulas Patocka
2018-08-08 12:16 ` Catalin Marinas
2018-08-08 13:02 ` David Laight
2018-08-08 13:46 ` Mikulas Patocka
2018-08-08 14:26 ` David Laight
2018-08-08 14:50 ` Catalin Marinas
2018-08-08 16:21 ` Mikulas Patocka
2018-08-08 16:31 ` Arnd Bergmann
2018-08-08 16:43 ` David Laight
2018-08-08 18:56 ` Mikulas Patocka
2018-08-08 18:37 ` Mikulas Patocka
2018-08-08 11:39 ` Catalin Marinas
2018-08-08 14:12 ` Mikulas Patocka
2018-08-08 14:28 ` Catalin Marinas
2018-08-08 18:40 ` Mikulas Patocka
2018-08-08 15:01 ` Richard Earnshaw (lists)
2018-08-08 15:14 ` Catalin Marinas
2018-08-08 16:01 ` Arnd Bergmann
2018-08-08 18:25 ` Mikulas Patocka
2018-08-08 21:51 ` Arnd Bergmann
2018-08-09 15:29 ` Arnd Bergmann
2018-08-03 7:11 ` Andrew Pinski
2018-08-03 7:53 ` Florian Weimer
2018-08-03 9:12 ` Szabolcs Nagy
2018-08-03 9:15 ` Ramana Radhakrishnan
2018-08-03 9:29 ` Ard Biesheuvel
2018-08-03 9:37 ` Ramana Radhakrishnan
2018-08-03 9:42 ` Richard Earnshaw (lists)
2018-08-04 0:58 ` Mikulas Patocka
2018-08-04 1:13 ` Andrew Pinski
2018-08-04 11:04 ` Mikulas Patocka [this message]
2018-08-05 18:33 ` Florian Weimer
2018-08-06 8:02 ` Mikulas Patocka
2018-08-06 8:10 ` Ard Biesheuvel
2018-08-06 10:31 ` Mikulas Patocka
2018-08-06 10:37 ` Ard Biesheuvel
2018-08-06 10:42 ` Mikulas Patocka
2018-08-06 10:48 ` Ard Biesheuvel
2018-08-06 12:09 ` Mikulas Patocka
2018-08-06 12:19 ` Ard Biesheuvel
2018-08-06 12:22 ` Ard Biesheuvel
2018-08-07 14:14 ` Mikulas Patocka
2018-08-07 14:40 ` Ard Biesheuvel
2018-08-08 19:15 ` Mikulas Patocka
2018-08-06 11:19 ` Siddhesh Poyarekar
2018-08-06 11:29 ` Ard Biesheuvel
2018-08-06 14:26 ` Tulio Magno Quites Machado Filho
2018-08-05 21:51 ` Pavel Machek
2018-08-06 14:30 ` Mikulas Patocka
2018-08-03 11:24 ` David Laight
2018-08-03 12:04 ` Mikulas Patocka
2018-08-03 13:04 ` David Laight
2018-08-05 14:36 ` Mikulas Patocka
2018-08-06 10:18 ` David Laight
2018-08-07 14:07 ` Mikulas Patocka
2018-08-07 14:33 ` David Laight
2018-08-08 14:21 ` Mikulas Patocka
2018-08-03 13:20 ` Mikulas Patocka
2018-08-03 13:31 ` Mikulas Patocka
2018-08-03 14:17 ` Richard Earnshaw (lists)
2018-08-05 21:36 ` Pavel Machek
2018-08-06 8:04 ` Ramana Radhakrishnan
2018-08-06 8:44 ` Pavel Machek
2018-08-06 9:11 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.02.1808040611070.23762@file01.intranet.prod.int.rdu2.redhat.com \
--to=mpatocka@redhat.com \
--cc=Richard.Earnshaw@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=pinskia@gmail.com \
--cc=ramana.gcc@googlemail.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).