On Wed, Aug 8, 2018 at 11:51 PM Arnd Bergmann wrote:
> I already found a couple of things:
>
> - Failure to copy always happens at the *end* of a 16 byte aligned
> physical address, it misses between 1 and 6 bytes, never 7 or more,
> and it's more likely to be fewer bytes that are affected.
>
On Wed, Aug 8, 2018 at 8:25 PM Mikulas Patocka wrote:
> On Wed, 8 Aug 2018, Arnd Bergmann wrote:
>
> > On Wed, Aug 8, 2018 at 5:15 PM Catalin Marinas
> > wrote:
> > >
> > > On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote:
> > > > On 08/08/18 15:12, Mikulas Patocka wrote:
> > > >
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> No that works fine for me. VDPAU acceleration works as well, but it
> depends on your chromium build whether it can actually use it, I
> think? In any case, mplayer can use vdpau to play 1080p h264 without
> breaking a sweat on this system.
I didn't
On Wed, 8 Aug 2018, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 08 August 2018 17:31
> ..
> > > They do modify the same byte, but with the same value. Suppose that you
> > > want to copy a piece of data that is between 8 and 16 bytes long. You can
> > > do this:
> > >
> > > add src_end,
On Wed, 8 Aug 2018, Catalin Marinas wrote:
> On Wed, Aug 08, 2018 at 10:12:27AM -0400, Mikulas Patocka wrote:
> > On Wed, 8 Aug 2018, Catalin Marinas wrote:
> > > On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> > > > while (1) {
> > > > start = (unsign
On Wed, 8 Aug 2018, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 08 August 2018 14:47
> ...
> > The problem on ARM is that I see data corruption when the overlapping
> > unaligned writes are done just by a single core.
>
> Is this a sequence of unaligned writes (that shouldn't modify
On Mon, 6 Aug 2018, Robin Murphy wrote:
> I would strongly suspect this issue is particular to Armada 8k, so its'
> probably one for the Marvell folks to take a closer look at - I believe
> some previous interconnect issues on those SoCs were actually fixable in
> firmware.
>
> Robin.
Do y
On Wed, 8 Aug 2018, Arnd Bergmann wrote:
> On Wed, Aug 8, 2018 at 5:15 PM Catalin Marinas
> wrote:
> >
> > On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote:
> > > On 08/08/18 15:12, Mikulas Patocka wrote:
> > > > On Wed, 8 Aug 2018, Catalin Marinas wrote:
> > > >> On Fri, Aug
From: Arnd Bergmann
> Sent: 08 August 2018 17:31
..
> > They do modify the same byte, but with the same value. Suppose that you
> > want to copy a piece of data that is between 8 and 16 bytes long. You can
> > do this:
> >
> > add src_end, src, len
> > add dst_end, dst, len
> > ldr x0, [src]
> > ld
On Wed, Aug 8, 2018 at 6:22 PM Mikulas Patocka wrote:
>
> On Wed, 8 Aug 2018, Catalin Marinas wrote:
>
> > On Wed, Aug 08, 2018 at 02:26:11PM +, David Laight wrote:
> > > From: Mikulas Patocka
> > > > Sent: 08 August 2018 14:47
> > > ...
> > > > The problem on ARM is that I see data corruption
On Wed, 8 Aug 2018, Catalin Marinas wrote:
> On Wed, Aug 08, 2018 at 02:26:11PM +, David Laight wrote:
> > From: Mikulas Patocka
> > > Sent: 08 August 2018 14:47
> > ...
> > > The problem on ARM is that I see data corruption when the overlapping
> > > unaligned writes are done just by a sin
On Wed, Aug 8, 2018 at 5:15 PM Catalin Marinas wrote:
>
> On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote:
> > On 08/08/18 15:12, Mikulas Patocka wrote:
> > > On Wed, 8 Aug 2018, Catalin Marinas wrote:
> > >> On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> - fai
On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote:
> On 08/08/18 15:12, Mikulas Patocka wrote:
> > On Wed, 8 Aug 2018, Catalin Marinas wrote:
> >> On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> >>> while (1) {
> >>> start = (unsigned)random() % (LEN +
On 08/08/18 15:12, Mikulas Patocka wrote:
>
>
> On Wed, 8 Aug 2018, Catalin Marinas wrote:
>
>> 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);
>>>
On Wed, Aug 08, 2018 at 02:26:11PM +, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 08 August 2018 14:47
> ...
> > The problem on ARM is that I see data corruption when the overlapping
> > unaligned writes are done just by a single core.
>
> Is this a sequence of unaligned writes (that
On Wed, Aug 08, 2018 at 10:12:27AM -0400, Mikulas Patocka wrote:
> On Wed, 8 Aug 2018, Catalin Marinas wrote:
> > On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> > > while (1) {
> > > start = (unsigned)random() % (LEN + 1);
> > > end = (unsigned)random() % (
From: Mikulas Patocka
> Sent: 08 August 2018 14:47
...
> The problem on ARM is that I see data corruption when the overlapping
> unaligned writes are done just by a single core.
Is this a sequence of unaligned writes (that shouldn't modify the
same physical locations) or an aligned write followed
On Tue, 7 Aug 2018, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 07 August 2018 15:07
> ...
> > Unaccelerated scrolling is still painfully slow
> > even on modern computers because of slow framebuffer read.
>
> I solved that many years ago on a strongarm system by mapping
> the screen
On Wed, 8 Aug 2018, Catalin Marinas wrote:
> 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)
> >
On Wed, 8 Aug 2018, Marcin Wojtas wrote:
> Hi Mikulas,
>
> wt., 7 sie 2018 o 19:39 Mikulas Patocka napisa?(a):
> >
> >
> >
> > On Tue, 7 Aug 2018, Marcin Wojtas wrote:
> >
> > > Ard, Mikulas,
> > >
> > > After some self-caused setup issues I was able to run the test on my
> > > MacchiatoBin w
On Wed, 8 Aug 2018, David Laight wrote:
> From: Catalin Marinas
> > Sent: 08 August 2018 13:17
> ...
> > I think hazarding is what goes wrong here, especially since with
> > overlapping unaligned addresses. However, I disagree that it is
> > impossible to implement this properly on a platform w
From: Catalin Marinas
> Sent: 08 August 2018 13:17
...
> I think hazarding is what goes wrong here, especially since with
> overlapping unaligned addresses. However, I disagree that it is
> impossible to implement this properly on a platform with PCIe so that
> Normal NC mappings can be used.
I've
Hi Matt,
On Fri, Aug 03, 2018 at 03:44:44PM -0500, Matt Sealey wrote:
> On 3 August 2018 at 13:25, Mikulas Patocka wrote:
> > On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
> >> Are we still talking about overlapping unaligned accesses here? Or do
> >> you see other failures as well?
> >
> > Yes - it
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 < e
On Tue, 7 Aug 2018, Ard Biesheuvel wrote:
> On 7 August 2018 at 19:39, Mikulas Patocka wrote:
> >
> >
> > On Tue, 7 Aug 2018, Marcin Wojtas wrote:
> >
> >> Ard, Mikulas,
> >>
> >> After some self-caused setup issues I was able to run the test on my
> >> MacchiatoBin with the kernel v4.18-rc8.
On 7 August 2018 at 19:39, Mikulas Patocka wrote:
>
>
> On Tue, 7 Aug 2018, Marcin Wojtas wrote:
>
>> Ard, Mikulas,
>>
>> After some self-caused setup issues I was able to run the test on my
>> MacchiatoBin with the kernel v4.18-rc8. It's been running for 1h+ now,
>> loading the CPU to 100% and no
On Tue, 7 Aug 2018, Marcin Wojtas wrote:
> Ard, Mikulas,
>
> After some self-caused setup issues I was able to run the test on my
> MacchiatoBin with the kernel v4.18-rc8. It's been running for 1h+ now,
> loading the CPU to 100% and no single error event...
>
> I built the binary file with:
>
Ard, Mikulas,
pon., 6 sie 2018 o 22:11 Ard Biesheuvel napisał(a):
>
> On 6 August 2018 at 21:54, Mikulas Patocka wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 19:09, Mikulas Patocka wrote:
> >> >
> >> >
> >> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
On 7 August 2018 at 16:14, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> No that works fine for me. VDPAU acceleration works as well, but it
>> depends on your chromium build whether it can actually use it, I
>> think? In any case, mplayer can use vdpau to play 1080p
From: Mikulas Patocka
> Sent: 07 August 2018 15:07
...
> Unaccelerated scrolling is still painfully slow
> even on modern computers because of slow framebuffer read.
I solved that many years ago on a strongarm system by mapping
the screen memory at two separate virtual addresses.
One uncached used
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> No that works fine for me. VDPAU acceleration works as well, but it
> depends on your chromium build whether it can actually use it, I
> think? In any case, mplayer can use vdpau to play 1080p h264 without
> breaking a sweat on this system.
>
> Note
On Mon, 6 Aug 2018, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 05 August 2018 15:36
> > To: David Laight
> ...
> > There's an instruction movntdqa (and vmovntdqa) that can actually do
> > prefetch on write-combining memory type. It's the only instruction that
> > can do it.
> >
> >
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> > Unfortunatelly, it doesn't work. I verified that the bit is set after
> > booting Linux, but the memcpy corruption was still present.
> >
> > I also tried the other chicken bits, it slowed down the system noticeably,
> > but had no effect on the mem
On 6 August 2018 at 21:54, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> On 6 August 2018 at 19:09, Mikulas Patocka wrote:
>> >
>> >
>> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>> >
>> >> On 6 August 2018 at 14:42, Robin Murphy wrote:
>> >> > On 06/08/18 11:25, M
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> On 6 August 2018 at 19:09, Mikulas Patocka wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 14:42, Robin Murphy wrote:
> >> > On 06/08/18 11:25, Mikulas Patocka wrote:
> >> > [...]
> >> >>>
> >> >>> None of t
On 6 August 2018 at 19:09, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, 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
>> >>> e
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 i
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
On Mon, 6 Aug 2018, 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 da
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, a
On Sun, 5 Aug 2018, Pavel Machek wrote:
> Hi!
>
> > > 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
Florian Weimer writes:
> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
>> 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 el
On Mon, 6 Aug 2018, Marcin Wojtas wrote:
> > Hi Marcin,
> >
> > Could you please try running his reproducer?
>
> This is exactly what I plan to do, as soon as I can plug my GFX card
> back to the board (tomorrow). Just to remain aligned - is it ok, if I
> boot my debian with GT630 plugged, com
Hi Ard, Mikulas,
pon., 6 sie 2018 o 15:48 Ard Biesheuvel napisał(a):
>
> On 6 August 2018 at 15:41, Marcin Wojtas wrote:
> > Hi Mikulas,
> >
> > pon., 6 sie 2018 o 14:42 Robin Murphy napisał(a):
> >>
> >> On 06/08/18 11:25, Mikulas Patocka wrote:
> >> [...]
> >> >> None of this explains why som
On 6 August 2018 at 15:41, Marcin Wojtas wrote:
> Hi Mikulas,
>
> pon., 6 sie 2018 o 14:42 Robin Murphy napisał(a):
>>
>> 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
Hi Mikulas,
pon., 6 sie 2018 o 14:42 Robin Murphy napisał(a):
>
> 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 c
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, a
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 n
On 6 August 2018 at 14:19, Ard Biesheuvel wrote:
> On 6 August 2018 at 14:09, Mikulas Patocka wrote:
>>
>>
>> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>>
>>> >> Are we talking about a quirk for the Armada 8040 or about PCIe on ARM
>>> >> in general?
>>> >
>>> > I don't know - there are not any o
On 6 August 2018 at 14:09, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> >> Are we talking about a quirk for the Armada 8040 or about PCIe on ARM
>> >> in general?
>> >
>> > I don't know - there are not any other easily available PCIe ARM boards
>> > except for Armada
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >> Are we talking about a quirk for the Armada 8040 or about PCIe on ARM
> >> in general?
> >
> > I don't know - there are not any other easily available PCIe ARM boards
> > except for Armada 8040.
>
> ... indeed, and sadly, the ones that are availab
On 6 August 2018 at 13:19, Siddhesh Poyarekar wrote:
> On 08/06/2018 04:01 PM, Mikulas Patocka wrote:
>>
>> I think there are three possible solutions:
>>
>> 1. provide an alternative memcpy implementation that doesn't do unaligned
>> accesses and recompile the graphics software with -mstrict-alig
On 08/06/2018 04:01 PM, Mikulas Patocka wrote:
I think there are three possible solutions:
1. provide an alternative memcpy implementation that doesn't do unaligned
accesses and recompile the graphics software with -mstrict-align
Given that there's already a tunable glibc.cpu.cached_memopt for
On 6 August 2018 at 12:42, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> On 6 August 2018 at 12:31, Mikulas Patocka wrote:
>> >
>> >
>> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>> >
>> >> On 6 August 2018 at 10:02, Mikulas Patocka wrote:
>> >> >
>> >> >
>> >> > O
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> On 6 August 2018 at 12:31, Mikulas Patocka wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 10:02, Mikulas Patocka wrote:
> >> >
> >> >
> >> > On Sun, 5 Aug 2018, Florian Weimer wrote:
> >> >
> >> >> On 08/04
On 6 August 2018 at 12:31, Mikulas Patocka wrote:
>
>
> On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
>
>> On 6 August 2018 at 10:02, Mikulas Patocka wrote:
>> >
>> >
>> > On Sun, 5 Aug 2018, Florian Weimer wrote:
>> >
>> >> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
>> >> > There's plenty of mem
On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> On 6 August 2018 at 10:02, Mikulas Patocka wrote:
> >
> >
> > On Sun, 5 Aug 2018, Florian Weimer wrote:
> >
> >> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
> >> > There's plenty of memcpy's in the graphics stack. No one will be
> >> > rewriting
On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
> On 3 August 2018 at 22:44, Matt Sealey wrote:
> > On 3 August 2018 at 13:25, Mikulas Patocka wrote:
> >>
> >>
> >> On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
> >>
> >>> Are we still talking about overlapping unaligned accesses here? Or do
> >>> you s
From: Mikulas Patocka
> Sent: 05 August 2018 15:36
> To: David Laight
...
> There's an instruction movntdqa (and vmovntdqa) that can actually do
> prefetch on write-combining memory type. It's the only instruction that
> can do it.
>
> It this instruction is used on non-write-combining memory type
On 6 August 2018 at 10:44, Pavel Machek wrote:
> 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.
>> >>
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 fra
On 6 August 2018 at 10:02, Mikulas Patocka wrote:
>
>
> On Sun, 5 Aug 2018, Florian Weimer wrote:
>
>> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
>> > 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
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, m
On Sun, 5 Aug 2018, Florian Weimer wrote:
> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
> > 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 thin
Hi!
> > 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.
I'm pretty sure it will wor
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 writes
> > on the framebuffer - nothing else.
On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
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
On Fri, 3 Aug 2018, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 03 August 2018 13:05
> ...
> > > Even on x86 using memcpy() on PCIe memory (maybe mmap()ed into userspace)
> > > isn't a good idea.
> > > In the kernel memcpy_to/fromio() ought to be a better choice but that
> > > is just
On Fri, 3 Aug 2018, Matt Sealey wrote:
> On 3 August 2018 at 13:25, Mikulas Patocka wrote:
> >
> >
> > On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
> >
> >> Are we still talking about overlapping unaligned accesses here? Or do
> >> you see other failures as well?
> >
> > Yes - it is caused by ove
On Fri, 3 Aug 2018, Andrew Pinski wrote:
> On Fri, Aug 3, 2018 at 5:58 PM Mikulas Patocka 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 a
On Fri, Aug 3, 2018 at 5:58 PM Mikulas Patocka 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.
> >
>
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
On 3 August 2018 at 22:44, Matt Sealey wrote:
> On 3 August 2018 at 13:25, Mikulas Patocka wrote:
>>
>>
>> On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
>>
>>> Are we still talking about overlapping unaligned accesses here? Or do
>>> you see other failures as well?
>>
>> Yes - it is caused by overlap
On 3 August 2018 at 13:25, Mikulas Patocka wrote:
>
>
> On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
>
>> Are we still talking about overlapping unaligned accesses here? Or do
>> you see other failures as well?
>
> Yes - it is caused by overlapping unaligned accesses inside memcpy. When I
> put "dmb
On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
> (- libc-alpha)
>
> On 3 August 2018 at 19:09, Mikulas Patocka wrote:
> >
> >
> > On Fri, 3 Aug 2018, Will Deacon wrote:
> >
> >> On Fri, Aug 03, 2018 at 09:16:39AM +0200, Ard Biesheuvel wrote:
> >> > On 3 August 2018 at 08:35, Mikulas Patocka wrote
(- libc-alpha)
On 3 August 2018 at 19:09, Mikulas Patocka wrote:
>
>
> On Fri, 3 Aug 2018, Will Deacon wrote:
>
>> On Fri, Aug 03, 2018 at 09:16:39AM +0200, Ard Biesheuvel wrote:
>> > On 3 August 2018 at 08:35, Mikulas Patocka wrote:
>> > >
>> > >
>> > > On Thu, 2 Aug 2018, Matt Sealey wrote:
>>
On 8/3/2018 1:09 PM, Mikulas Patocka wrote:
Most accelerated graphics drivers rely heavily on the ability to map
the VRAM normal-non-cacheable (ioremap_wc, basically), and treat it as
ordinary memory.
Yeah, I'd expect framebuffers to be mapped as normal NC. That should be
fine for prefetchable B
On Fri, 3 Aug 2018, Will Deacon wrote:
> On Fri, Aug 03, 2018 at 09:16:39AM +0200, Ard Biesheuvel wrote:
> > On 3 August 2018 at 08:35, Mikulas Patocka wrote:
> > >
> > >
> > > On Thu, 2 Aug 2018, Matt Sealey wrote:
> > >
> > >> The easiest explanation for this would be that the memory isn?t m
On 03/08/18 14:31, Mikulas Patocka wrote:
>
>
> On Fri, 3 Aug 2018, Andrew Pinski wrote:
>
>> On Thu, Aug 2, 2018 at 12:31 PM Mikulas Patocka 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 bro
On Fri, 3 Aug 2018, Andrew Pinski wrote:
> On Thu, Aug 2, 2018 at 12:31 PM Mikulas Patocka 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
>
On Fri, 3 Aug 2018, Florian Weimer wrote:
> On 08/03/2018 09:11 AM, Andrew Pinski wrote:
> > Yes fix Links not to use memcpy on the framebuffer.
> > It is undefined behavior to use device memory with memcpy.
>
> Some (de facto) ABIs require that it is supported, though. For example,
> the PO
From: Mikulas Patocka
> Sent: 03 August 2018 13:05
...
> > Even on x86 using memcpy() on PCIe memory (maybe mmap()ed into userspace)
> > isn't a good idea.
> > In the kernel memcpy_to/fromio() ought to be a better choice but that
> > is just an alternate name for memcpy().
> >
> > The problem on x8
On Fri, 3 Aug 2018, David Laight wrote:
> From: Ard Biesheuvel
> > Sent: 03 August 2018 10:30
> ...
> > The discussion about whether memcpy() should rely on unaligned
> > accesses, and whether you should use it on device memory is orthogonal
> > to that, and not the heart of the matter IMO
>
>
From: Ard Biesheuvel
> Sent: 03 August 2018 10:30
...
> The discussion about whether memcpy() should rely on unaligned
> accesses, and whether you should use it on device memory is orthogonal
> to that, and not the heart of the matter IMO
Even on x86 using memcpy() on PCIe memory (maybe mmap()ed i
On 03/08/18 10:29, Ard Biesheuvel wrote:
> On 3 August 2018 at 11:15, Ramana Radhakrishnan
> wrote:
>> On Fri, Aug 3, 2018 at 8:53 AM, Florian Weimer wrote:
>>> On 08/03/2018 09:11 AM, Andrew Pinski wrote:
Yes fix Links not to use memcpy on the framebuffer.
It is undefined behavior
On Fri, Aug 03, 2018 at 09:16:39AM +0200, Ard Biesheuvel wrote:
> On 3 August 2018 at 08:35, Mikulas Patocka wrote:
> >
> >
> > On Thu, 2 Aug 2018, Matt Sealey wrote:
> >
> >> The easiest explanation for this would be that the memory isn?t mapped
> >> correctly. You can?t use PCIe memory spaces wi
< snip>
> I guess the semantics of a framebuffer are not strictly defined, but
> the current reality is that it is expected to have memory semantics
> (by Linux/glibc)
>
> Matt is saying fundamental properties of the underlying interconnects
> (AMBA) make that impossible on ARM, but I'd like to un
On 3 August 2018 at 11:15, Ramana Radhakrishnan
wrote:
> On Fri, Aug 3, 2018 at 8:53 AM, Florian Weimer wrote:
>> On 08/03/2018 09:11 AM, Andrew Pinski wrote:
>>>
>>> Yes fix Links not to use memcpy on the framebuffer.
>>> It is undefined behavior to use device memory with memcpy.
>>
>>
>> Some (
On Fri, Aug 3, 2018 at 8:53 AM, Florian Weimer wrote:
> On 08/03/2018 09:11 AM, Andrew Pinski wrote:
>>
>> Yes fix Links not to use memcpy on the framebuffer.
>> It is undefined behavior to use device memory with memcpy.
>
>
> Some (de facto) ABIs require that it is supported, though. For example
On 03/08/18 08:53, Florian Weimer wrote:
On 08/03/2018 09:11 AM, Andrew Pinski wrote:
Yes fix Links not to use memcpy on the framebuffer.
It is undefined behavior to use device memory with memcpy.
Some (de facto) ABIs require that it is supported, though. For example, the POWER string functio
On 08/03/2018 09:11 AM, Andrew Pinski wrote:
Yes fix Links not to use memcpy on the framebuffer.
It is undefined behavior to use device memory with memcpy.
Some (de facto) ABIs require that it is supported, though. For example,
the POWER string functions avoid unaligned loads and stores for t
On 3 August 2018 at 08:35, Mikulas Patocka wrote:
>
>
> On Thu, 2 Aug 2018, Matt Sealey wrote:
>
>> The easiest explanation for this would be that the memory isn?t mapped
>> correctly. You can?t use PCIe memory spaces with anything other than
>> Device-nGnRE or stricter mappings. That?s just diffe
On Thu, Aug 2, 2018 at 12:31 PM Mikulas Patocka 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-
On Thu, 2 Aug 2018, Matt Sealey wrote:
> The easiest explanation for this would be that the memory isn?t mapped
> correctly. You can?t use PCIe memory spaces with anything other than
> Device-nGnRE or stricter mappings. That?s just differences between the
> AMBA and PCIe (posted/unposted) me
The easiest explanation for this would be that the memory isn’t mapped
correctly. You can’t use PCIe memory spaces with anything other than
Device-nGnRE or stricter mappings. That’s just differences between the AMBA
and PCIe (posted/unposted) memory models.
Normal memory (cacheable or uncacheable,
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 writes
on the framebuffer - nothing else.
I found out that th
96 matches
Mail list logo
