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 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 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 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
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
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 =
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 =
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 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
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
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
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]
> >
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]
> >
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
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
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
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
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:
> -
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:
> -
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 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 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
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
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() %
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
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
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
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, 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
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
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
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
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.
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.
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
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 <
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 <
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 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
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
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:
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
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
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
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
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
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, 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, 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
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
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,
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,
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
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
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
>> >>>
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
>> >>>
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
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
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
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
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
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
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,
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,
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
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
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
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,
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,
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
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
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
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
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
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,
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,
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
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
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
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
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
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
1 - 100 of 190 matches
Mail list logo
