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

[Luís Mendes]

Hi,

On Thu, Aug 31, 2017 at 9:41 AM, Russell King - ARM Linux <
linux at armlinux.org.uk> wrote:

> 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?
>
>
I've conducted further tests with a imx6q and a imx6qp with the same
connected monitor and resolution of 1024x768.
I modified the code of etnaviv_accel.c to the imx6qp to:

void etnaviv_accel_CopyNtoN(..) {
...
if (pSrc->height < pDst->height) {
        syslog(LOG_WARNING, "Mismatch src(y=%d,h=%d), dst(y=%d,h=%d),
dy=%d\n", pSrc->y, pSrc->height, pDst->y, pDst->height, dy);
        goto fallback;
}

which is enough to mask the copy area problems.

On the imx6q I modified it to:

void etnaviv_accel_CopyNtoN(..) {
...
if (pSrc->height < pDst->height) {
        syslog(LOG_WARNING, "Mismatch src(y=%d,h=%d), dst(y=%d,h=%d),
dy=%d\n", pSrc->y, pSrc->height, pDst->y, pDst->height, dy);
}


The imx6q is not showing any issues on this Ubuntu Mate 17.04, even for the
conditions:
Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24),
dst(y=0,h=25), dy=0
Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24),
dst(y=-25,h=25), dy=25
Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=1),
dst(y=-25,h=25), dy=1
Aug 31 11:58:12 picolo etnaviv[4694]: Mismatch src(y=0,h=1), dst(y=0,h=25),
dy=0

No MMU faults, no screen corruptions.


The imx6qp always have MMU faults and is showing the issues when removing
the "goto callback" instruction.
Aug 30 18:41:32 picolo etnaviv[1722]: Mismatch src(y=0,h=24),
dst(y=0,h=25), dy=0
Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=24),
dst(y=-25,h=25), dy=25
Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=1),
dst(y=-25,h=25), dy=1
Aug 30 18:41:41 picolo etnaviv[1722]: Mismatch src(y=0,h=1), dst(y=0,h=25),
dy=0

This probably indicates that there is no implementation issue with CopyNtoN
and this is rather a side effect of the MMU faults.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20170831/11d7e685/attachment.html>