etnaviv-gpu 134000.gpu: MMU fault status 0x00000002 on i.XM6 Quad Plus

[Russell King - ARM Linux]

On Wed, Aug 30, 2017 at 06:40:09PM +0100, Luís Mendes wrote:
> Hi,
> 
> I've reduced the set of cases that cause the copy areas to fail to single
> logic condition on void etnaviv_accel_CopyNtoN(...).
> I was able to fix the screen with:
> ...
> if (pSrc->height != pDst->height) {
>         syslog(LOG_WARNING, "Mismatch src.w=%d, dst.w=%d\n", pSrc->height,
> pDst->height);
>         goto fallback;
> }
> ...
> 
> What is happening is that areas that fail to copy have a pSrc.height value
> of 24 pixels, but pDst.height value of 25 pixels, etc.

It's also important to know the pSrc and pDst y, and dy values.

If these are all zero, what we're being asked to do is to copy a
drawable that is 24 pixels high into the top of a drawable that is
25 pixels high.  This function is only (afaik) defined for copying.
So what should it be doing with the extra line that the destination
has if the set of boxes are requesting that line be written?

from what I can see in the Xorg fb layer, it entirely ignores the
boundaries of the drawable, and just copies from the source even if
this means overflowing its width and height, which sounds very
problematical as that can end up running off the end of the allcoated
memory - or in the case of a GPU, end up running off the end of the
mapped buffer and causing GPU faults / crashes.

However, miDoCopy() should be generating exposures for those areas
(see the comments in the Xorg source above miHandleExposures().)  It
sounds like this is failing in some way, but that is all generic Xorg
code, so should afflict all DDX drivers including the fallbacks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up