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

[Luís Mendes]

Hi Russell,

Great news! The issue we were getting with copyNtoN(...) is just a side
effect of etnaviv_render.c - etnaviv_acquire_src().
The root cause of the MMU falts is etnaviv_render.c - etnaviv_acquire_src().

I have enabled copyNtoN(...), but made etnaviv_acquire_src(...) always go
to fallback and now I am able to log into Ubuntu MATE without any MMU
faults.
I will include debug logs and get back with them.

 static struct etnaviv_pixmap *etnaviv_acquire_src(ScreenPtr pScreen,
        PicturePtr pict, const BoxRec *clip, PixmapPtr *ppPixTemp,
        xPoint *src_topleft, Bool force_vtemp)
{
        struct etnaviv *etnaviv = etnaviv_get_screen_priv(pScreen);
        struct etnaviv_pixmap *vSrc, *vTemp;
        struct etnaviv_blend_op copy_op;
        DrawablePtr drawable;
        uint32_t colour;
        xPoint src_offset;
        int tx, ty;

        goto fallback;
        ...

Luis

On Thu, Nov 2, 2017 at 11:51 PM, Russell King - ARM Linux <
linux at armlinux.org.uk> wrote:

> On Thu, Nov 02, 2017 at 11:10:33PM +0000, Luís Mendes wrote:
> > Even if I make all calls of copyNtoN(...) go to the unaccelerated
> fallback
> > the MMUs still occur in the same amount.
>
> I've looked at your emails so far - I don't think you're selecting the
> correct one.  Yes, you're finding those with a destination pixmap size
> of the required size, but remember that the clip window was 1024x24.
> We're looking for one where the extent matches that.
>
> > I get this different kernel MMU fault:
> > === Register dump
> > 0000000c = 000000df
> > 00000000 = 00040900
> > 00000004 = 7ffffff8 Idle: FE- DE- PE- SH+ PA+ SE+ RA+ TX+ VG+ IM+ FP+ TS+
> > 00000008 = 00002200
> > 00000014 = ffffffff
> > 00000018 = 14010000
> > 0000001c = e02c7eca
> > 00000020 = 00000320
> > 00000024 = 00005303
> > 00000028 = 20140510
> > 0000002c = 20353900
> > 00000034 = e9399eff
> > 00000038 = e9399eff
> > 00000070 = 00000000
> > 00000100 = 00140021
> > 00000104 = 00000000
> > 00000108 = 000000fa
> > 0000010c = 00000000
> > 00000400 = 00000000
> > 00000404 = 00000000
> > 00000408 = 00000000
> > 0000040c = 00000000
> > 00000410 = 00000000
> > 00000414 = 3c000000
> > 00000418 = 00000000
> > 0000041c = 00000000
> > 00000420 = 00000000
> > 00000424 = 00000000
> > 00000428 = 00000000
> > 0000042c = 00030000
> > 00000480 = 000000a8
> > 0000065c = 00000001
> > 00000660 = 00000803 Cmd: [load0 DMA: idle Fetch: valid] Req idle Cal idle
> > 00000664 = 000010b0 Command DMA address
> > === Buffers
> >  Num Name  IOVA     Size
> >    0 reg   00000000 00000128      296
> >    1 mmu   00000000 00401000  4198400
> >    2 ring  00000000 00001000     4096
> > *  3 cmd   00001000 000001a0      416
> >    4 cmd   00002000 00000190      400
> >    5 cmd   00003000 000001a0      416
> >    6 cmd   00004000 00000190      400
> >    7 bomap 00000000 000018d8     6360
> >    8 bo    00040000 00300000  3145728
> >    9 bo    00340000 00001000     4096
> >   10 bo    02316000 00001000     4096
> >   11 bo    0231e000 00001000     4096
> >   12 bo    02320000 00018000    98304
> > Checking MMU entries... ok
>
> 00000: 08050480 00040000  LDST 0x1200=0x00040000
>                 00001000  LDST 0x1204=0x00001000
>                 00000000  LDST 0x1208=0x00000000
>                 06000046  LDST 0x120c=0x06000046
>                 ffe80000  LDST 0x1210=0xffe80000
> 00018: 0804048a 02320000  LDST 0x1228=0x02320000
>                 00001000  LDST 0x122c=0x00001000
>                 00000000  LDST 0x1230=0x00000000
>                 00002006  LDST 0x1234=0x00002006
> 00030: 0802049f 00ff0001  LDST 0x127c=0x00ff0001
>                 01000100  LDST 0x1280=0x01000100
> 00040: 080304b2 ff000000  LDST 0x12c8=0xff000000
>                 00000000  LDST 0x12cc=0x00000000
>                 00000000  LDST 0x12d0=0x00000000
> 00050: 08030497 0030cccc  LDST 0x125c=0x0030cccc
>                 00000000  LDST 0x1260=0x00000000
>                 00180400  LDST 0x1264=0x00180400
> 00060: 20000100 00000000
>                             00000000 00180400  0,-24,1024,0 -> 0,0,1024,24
>         Blit: Dst:02320000 Src:00040000 Clip 0,0,1024,24
>         Src: 0x00040000-0x00041000 (1024,0)
>         Dst: 0x02320000-0x02339000 (1024,24)
>
> This shows the same issue - a destination overrun.  Digging a bit
> further into the dump shows that the states at 0x127c, 0x1280, 0x12c8
> indicate that it's actually a blend operation, looks like PictOpSrc
> with a source global alpha of 0xff.
>
> That would make the operation from copy_to_vtemp in
> etnaviv_acquire_src().
>
> The other thing I notice is the source top y is -24, which is definitely
> wrong.  Hmm, not sure quite what to make of that just yet...  I'll
> think on it.
>
> --
> 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/20171103/7a074f9d/attachment.html>