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

[Luís Mendes]

Hi Lucas, Russel,

On Wed, Aug 30, 2017 at 1:23 PM, Lucas Stach <l.stach at pengutronix.de> wrote:

> Am Mittwoch, den 30.08.2017, 12:52 +0100 schrieb Russell King - ARM
> Linux:
> > On Wed, Aug 30, 2017 at 12:20:32PM +0100, Luís Mendes wrote:
> > > I've found a couple of minutes to test these and I have found that on
> > > iMX6QP:
> > >
> > > static RegionPtr
> > > etnaviv_CopyArea(DrawablePtr pSrc, DrawablePtr pDst, GCPtr pGC,
> > >     int srcx, int srcy, int w, int h, int dstx, int dsty)
> > >
> > > when forcing the unaccel call, no missing text areas occur in the
> menus and
> > > dialog windows, however the MMU fault still occur.
> >
> > It would be good to know the failure case - this has been tested with
> > the various X test programs which do not reveal any issues with it.
> >
> > I've found it rather difficult and very time consuming to setup test
> > scenarios for issues that other people see with my DDX driver (which
> > basically mean downloading an entire distro and trying to replicate
> > their setup.)
>

I can provide a full SD card image that exhibits all the issues I have been
reporting on the IMX6QP.

>
> > > The MMU fault seem to not cause any visibile disruption, in fact, if I
> > > disable all acceleration functions in the function below, like shown:
> > >
> > >
> > > static void
> > > etnaviv_ValidateGC(GCPtr pGC, unsigned long changes, DrawablePtr
> > > pDrawable)  {
> > > ...
> > > /* if (!etnaviv->force_fallback && etnaviv_GC_can_accel(pGC,
> pDrawable))
> > >         pGC->ops = &etnaviv_GCOps;
> > >     else */
> > >         pGC->ops = &etnaviv_unaccel_GCOps;
> > >
> > > The MMU faults still occur.
> >
> > That doesn't disable /all/ acceleration functions.  That disables the
> > acceleration functions for the GC - in other words, operations that
> > require a graphic context.  There's a number of other operations that
> > the backend can use that do not use a GC and are unaffected by this.
> > CopyWindow is one such example, but also the Render backend as well.
>
Ok, I understand! I have however also tried to force the unacell call
function by function on etnaviv.c
by commenting out the acceleration calls and issue persists. Possibly there
are other files that I will have to address too,
to see if I find the "culprit function".


> >
> > Now, all that said, this could be due to a known GC320 bug: the GC320
> > fails to properly flush its caches after performing operations even if
> > you ask it to.  In order to work around this, it is necessary to insert
> > into the command stream an additional copy operation.  That copy
> > operation pushes the previous operation out of the GC320's caches, but
> > it could very well result in this very operation also falling foul of
> > the very same bug (the difference being that its with the dummy buffer
> > rather than with a real buffer, so the user shouldn't see any on-screen
> > corruption.)
>
> This issue is no longer present in the GC320 revision on the QuadPlus.
> In fact I have a local patch to disable the workaround for this GC320
> revision and have been unable to trigger the bug with a testcase that
> was easily hitting the issue on the Quad/Duallite.
>
>
In summay I believe to have found three different issues:
1 - Screen blanking on kernels >= 4.12.0
2 - MMU faults when login in into Ubuntu Mate 17.04 (no screen corruption
is visible)
3 - Bug on etnaviv_accel_CopyNtoN(...) which fails to copy some areas
containing text into the desktop, X menus and dialog windows. I am trying
to collect additional data on this one.


> Regards,
> Lucas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20170830/dfc95f98/attachment.html>