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

[Luís Mendes]

Hi Lucas,

On Wed, Aug 30, 2017 at 11:31 AM, Lucas Stach <l.stach at pengutronix.de>
wrote:

> Am Mittwoch, den 30.08.2017, 11:20 +0100 schrieb Luís Mendes:
> >
> > On Wed, Aug 30, 2017 at 10:56 AM, Lucas Stach <l.stach at pengutronix.de>
> > wrote:
> >         Am Mittwoch, den 30.08.2017, 10:46 +0100 schrieb Luís Mendes:
> >         > Hi Lucas,
> >         >
> >         >
> >         > I see in xf86-video-armada/etnaviv/etnaviv.c, that each of
> >         the
> >         > functions etnaviv_PolyLines,..., has a respective fallback
> >         function
> >         > call name unaccel_...
> >         >
> >         >
> >         > When you say disable individual acceleration function, you
> >         are saying
> >         > to force the call to the respective unaccel function?
> >         >
> >         Yes, this way you should be able to narrow down which of the
> >         acceleration functions is causing the GPU MMU faults. When you
> >         have that
> >         you can dump the parameters for all invocations of this
> >         function, to
> >         figure out why the GPU is accessing invalid memory regions.
> >
> >
> > Ok, I'll try to do that as soon as I find some spare time.
>

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.
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.



> >
> >
> > Regarding the screen blanking do you have a suggestion on how to debug
> > it? I found that it is related with the prefetech unit enablement
> > introduced in kernel 4.12.0, kernels 4.11.x do not exhibit such
> > behaviour. What is happening is that when the X session is started for
> > the login screen, sometimes the mouse arrow is seen for a second and
> > then the screen blanks, sometimes the whole login screen can be seen
> > for 10 seconds or so, and then either blanks or shows a corrupted
> > screen image. Sometimes nothing is seen and screen just blanks before
> > the X session starts.
>
> Make sure to use an upstream DT, where the PRE/PRG units are actually
> used. The IPU driver will switch to using low-priority IPU channels when
> it's on a QuadPlus IPU, which will starve the display when the PRG/PRE
> units aren't set up correctly.
>
In respect to the DT, I believe I don't have to do any special
configuration other than include imx6qp.dtsi from the upstream, it where
pre and prg units are defined, and I am already doing that. I see no other
board DT file to add any further configurations to it.

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