<div dir="ltr"><div><div><div><div>Hi Russell,<br><br></div>Great news! The issue we were getting with copyNtoN(...) is just a side effect of etnaviv_render.c - etnaviv_acquire_src().<br></div>The root cause of the MMU falts is etnaviv_render.c - etnaviv_acquire_src().<br><br></div>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.</div><div>I will include debug logs and get back with them.<br></div><div><br> static struct etnaviv_pixmap *etnaviv_acquire_src(ScreenPtr pScreen,<br>        PicturePtr pict, const BoxRec *clip, PixmapPtr *ppPixTemp,<br>        xPoint *src_topleft, Bool force_vtemp)<br>{<br>        struct etnaviv *etnaviv = etnaviv_get_screen_priv(pScreen);<br>        struct etnaviv_pixmap *vSrc, *vTemp;<br>        struct etnaviv_blend_op copy_op;<br>        DrawablePtr drawable;<br>        uint32_t colour;<br>        xPoint src_offset;<br>        int tx, ty;<br><br>        goto fallback;<br></div>        ...<br><div class="gmail_extra"><br></div><div class="gmail_extra">Luis<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 11:51 PM, Russell King - ARM Linux <span dir="ltr"><<a href="mailto:linux@armlinux.org.uk" target="_blank">linux@armlinux.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Nov 02, 2017 at 11:10:33PM +0000, Luís Mendes wrote:<br>
> Even if I make all calls of copyNtoN(...) go to the unaccelerated fallback<br>
> the MMUs still occur in the same amount.<br>
<br>
</span>I've looked at your emails so far - I don't think you're selecting the<br>
correct one.  Yes, you're finding those with a destination pixmap size<br>
of the required size, but remember that the clip window was 1024x24.<br>
We're looking for one where the extent matches that.<br>
<div><div class="h5"><br>
> I get this different kernel MMU fault:<br>
> === Register dump<br>
> 0000000c = 000000df<br>
> 00000000 = 00040900<br>
> 00000004 = 7ffffff8 Idle: FE- DE- PE- SH+ PA+ SE+ RA+ TX+ VG+ IM+ FP+ TS+<br>
> 00000008 = 00002200<br>
> 00000014 = ffffffff<br>
> 00000018 = 14010000<br>
> 0000001c = e02c7eca<br>
> 00000020 = 00000320<br>
> 00000024 = 00005303<br>
> 00000028 = 20140510<br>
> 0000002c = 20353900<br>
> 00000034 = e9399eff<br>
> 00000038 = e9399eff<br>
> 00000070 = 00000000<br>
> 00000100 = 00140021<br>
> 00000104 = 00000000<br>
> 00000108 = 000000fa<br>
> 0000010c = 00000000<br>
> 00000400 = 00000000<br>
> 00000404 = 00000000<br>
> 00000408 = 00000000<br>
> 0000040c = 00000000<br>
> 00000410 = 00000000<br>
> 00000414 = 3c000000<br>
> 00000418 = 00000000<br>
> 0000041c = 00000000<br>
> 00000420 = 00000000<br>
> 00000424 = 00000000<br>
> 00000428 = 00000000<br>
> 0000042c = 00030000<br>
> 00000480 = 000000a8<br>
> 0000065c = 00000001<br>
> 00000660 = 00000803 Cmd: [load0 DMA: idle Fetch: valid] Req idle Cal idle<br>
> 00000664 = 000010b0 Command DMA address<br>
</div></div><span class="">> === Buffers<br>
>  Num Name  IOVA     Size<br>
>    0 reg   00000000 00000128      296<br>
>    1 mmu   00000000 00401000  4198400<br>
>    2 ring  00000000 00001000     4096<br>
> *  3 cmd   00001000 000001a0      416<br>
>    4 cmd   00002000 00000190      400<br>
>    5 cmd   00003000 000001a0      416<br>
>    6 cmd   00004000 00000190      400<br>
>    7 bomap 00000000 000018d8     6360<br>
>    8 bo    00040000 00300000  3145728<br>
>    9 bo    00340000 00001000     4096<br>
>   10 bo    02316000 00001000     4096<br>
>   11 bo    0231e000 00001000     4096<br>
>   12 bo    02320000 00018000    98304<br>
> Checking MMU entries... ok<br>
<br>
</span>00000: 08050480 00040000  LDST 0x1200=0x00040000<br>
<span class="">                00001000  LDST 0x1204=0x00001000<br>
                00000000  LDST 0x1208=0x00000000<br>
                06000046  LDST 0x120c=0x06000046<br>
                ffe80000  LDST 0x1210=0xffe80000<br>
</span>00018: 0804048a 02320000  LDST 0x1228=0x02320000<br>
<span class="">                00001000  LDST 0x122c=0x00001000<br>
                00000000  LDST 0x1230=0x00000000<br>
                00002006  LDST 0x1234=0x00002006<br>
</span>00030: 0802049f 00ff0001  LDST 0x127c=0x00ff0001<br>
                01000100  LDST 0x1280=0x01000100<br>
00040: 080304b2 ff000000  LDST 0x12c8=0xff000000<br>
<span class="">                00000000  LDST 0x12cc=0x00000000<br>
                00000000  LDST 0x12d0=0x00000000<br>
</span>00050: 08030497 0030cccc  LDST 0x125c=0x0030cccc<br>
<span class="">                00000000  LDST 0x1260=0x00000000<br>
                00180400  LDST 0x1264=0x00180400<br>
</span>00060: 20000100 00000000<br>
<span class="">                            00000000 00180400  0,-24,1024,0 -> 0,0,1024,24<br>
</span>        Blit: Dst:02320000 Src:00040000 Clip 0,0,1024,24<br>
        Src: 0x00040000-0x00041000 (1024,0)<br>
        Dst: 0x02320000-0x02339000 (1024,24)<br>
<br>
This shows the same issue - a destination overrun.  Digging a bit<br>
further into the dump shows that the states at 0x127c, 0x1280, 0x12c8<br>
indicate that it's actually a blend operation, looks like PictOpSrc<br>
with a source global alpha of 0xff.<br>
<br>
That would make the operation from copy_to_vtemp in<br>
etnaviv_acquire_src().<br>
<br>
The other thing I notice is the source top y is -24, which is definitely<br>
wrong.  Hmm, not sure quite what to make of that just yet...  I'll<br>
think on it.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
RMK's Patch system: <a href="http://www.armlinux.org.uk/developer/patches/" rel="noreferrer" target="_blank">http://www.armlinux.org.uk/<wbr>developer/patches/</a><br>
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up<br>
According to <a href="http://speedtest.net" rel="noreferrer" target="_blank">speedtest.net</a>: 8.21Mbps down 510kbps up<br>
</div></div></blockquote></div><br></div></div>