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) > > 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). I triad to insert usleep(10000) between the memcpy and memcmp, but the same corruption occurs. So, it can't be read-after-write hazard. It is caused by the improper handling of hazard between the overlapping writes inside memcpy. Mikulas
- Re: framebuffer cor... Ard Biesheuvel
- Re: framebuffer... Ard Biesheuvel
- Re: framebuffer... Mikulas Patocka
- Re: framebuffer... Ard Biesheuvel
- Re: framebuffer... Mikulas Patocka
- Re: framebuffer corruption due to ov... Siddhesh Poyarekar
- Re: framebuffer corruption due t... Ard Biesheuvel
- Re: framebuffer corruption due to overlap... Tulio Magno Quites Machado Filho
- Re: framebuffer corruption due to overlap... Mikulas Patocka
- Re: framebuffer corruption due to overlap... Catalin Marinas
- Re: framebuffer corruption due to ov... Mikulas Patocka
- Re: framebuffer corruption due t... Catalin Marinas
- Re: framebuffer corruption d... Mikulas Patocka
- Re: framebuffer corruption due t... Richard Earnshaw (lists)
- Re: framebuffer corruption d... Catalin Marinas
- Re: framebuffer corrupti... Arnd Bergmann
- Re: framebuffer cor... Mikulas Patocka
- Re: framebuffer... Arnd Bergmann
- Re: framebuffer... Arnd Bergmann
- Re: framebuffer corruption due to overlap... Catalin Marinas
- RE: framebuffer corruption due to ov... David Laight