<div dir="ltr"><div><div><div><div><div>Hi,<br></div><div><br></div><div>Russel: I believe that the video corruption I saw with copyNToN(...) function of xf86-video-armada is not the root cause of the problem, but rather a side effect of the MMU faults.<br></div><div>Can you help me setup a debug environment where I can dump the client process stack from the etnaviv kernel module upon a MMU fault? I have enough space on my SSD drive to dump the memory images.<br></div><div>Otherwise it will be difficult for me to find the cause of the MMU faults. I already disabled as much hardware acceleration as I could from xf86-video-armada, but is not enough to avoid the MMU faults.</div><div>I could try to GDB xorg-server-core, but it may not be the direct cause for the MMU faults and I don't know where to look... stepping trhorugh xorg until the MMU faults occur is also unfeasible, I think.<br></div><div><br></div>I've just installed Ubuntu MATE 17.10 and Ubuntu desktop 17.10 on my Wandboard QuadPlus using Linux kernel<br></div> 4.14-rc5.<br><br></div>The MMU faults still happen with Ubuntu MATE 17.10 upon login, but not with Ubuntu Desktop 17.10.<br></div>Furthermore if using lightdm as display manager, instead of gdm, the Ubuntu MATE shows even worse screen corruption, as menus and dialogs are just a white rectangle with no text or buttons rendered.<br><br></div><div>Regards,</div><div>Luís<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 9:45 PM, Luís Mendes <span dir="ltr"><<a href="mailto:luis.p.mendes@gmail.com" target="_blank">luis.p.mendes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Russel, Lucas,<br><div class="gmail_extra"><div><div class="m_2532771458756066591gmail-im"><br></div><div class="m_2532771458756066591gmail-im">I have some news regarding the above topic...</div><div class="m_2532771458756066591gmail-im">I was supposed to check the X server API, but unfortunately I still didn't find the time to do it, however I've noticed that these commits in linux-4.14-rc5 improve the situation regarding the corrupted screen and screen blanking in the Ubuntu Mate 17.04 login screen with i.MX6 Quad Plus:</div><div class="m_2532771458756066591gmail-im"><div><br></div><div><b>gpu: ipu-v3: pre: implement workaround for ERR009624</b></div><div><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.14-rc6&id=11aff4b4c7c4b7257660ef890920f2ac72911ed0" target="_blank">https://git.kernel.org/pub/scm<wbr>/linux/kernel/git/torvalds/lin<wbr>ux.git/commit/?h=v4.14-rc6&id=<wbr>11aff4b4c7c4b7257660ef890920f2<wbr>ac72911ed0</a> <br></div><div><b><br></b></div><div><b>gpu: ipu-v3: prg: wait for double buffers to be filled on channel startup</b> <br></div><div><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.14-rc6&id=263c3b8044f9c9356a34fdb2640b52d27e378f9c" target="_blank">https://git.kernel.org/pub/scm<wbr>/linux/kernel/git/torvalds/lin<wbr>ux.git/commit/?h=v4.14-rc6&id=<wbr>263c3b8044f9c9356a34fdb2640b52<wbr>d27e378f9c</a></div><div><br></div><div><b>gpu: ipu-v3: Allow channel burst locking on i.MX6 only</b></div><div><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.14-rc6&id=cda77556447c782b3c9c068f81ef58136cb487c3" target="_blank">https://git.kernel.org/pub/scm<wbr>/linux/kernel/git/torvalds/lin<wbr>ux.git/commit/?h=v4.14-rc6&id=<wbr>cda77556447c782b3c9c068f81ef58<wbr>136cb487c3</a><b><br></b></div><span class="m_2532771458756066591gmail-im"><div><b><br></b></div><div>I've just tested kernel 4.14-rc5 on my Wandboard Quad Plus and it is able to display the login screen without blanking or corrupting the image, while in linux-4.13 it wasn't working. I used the new Fabio's DTBs for the Wandboard Quad Plus rev. D1 in both kernel versions. These DTBs fix the problem I was having with corrupted screen during early boot, but not the login screen.<br></div><div><br></div><div>Unfortunately the MMU faults remain along with the missing text in menus and icons as already reported.</div><div><br></div><div>I would like to contribute more to this topic, but unfortunately I am not being able to find the time do it. <br></div><div><br></div><div>Regards,</div><div>Luís Mendes<br></div><div><b></b></div><div><b></b></div></span></div><div class="m_2532771458756066591gmail-im"><br><div class="gmail_quote">On Thu, Aug 31, 2017 at 1:44 PM, Lucas Stach <span dir="ltr"><<a href="mailto:l.stach@pengutronix.de" target="_blank">l.stach@pengutronix.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>Am Donnerstag, den 31.08.2017, 13:36 +0100 schrieb Luís Mendes:<br>
<br>
<br>
<br>
> The imx6q is not showing any issues on this Ubuntu Mate 17.04, even<br>
> for the conditions:<br>
> Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24),<br>
> dst(y=0,h=25), dy=0<br>
> Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24),<br>
> dst(y=-25,h=25), dy=25<br>
> Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=1),<br>
> dst(y=-25,h=25), dy=1<br>
> Aug 31 11:58:12 picolo etnaviv[4694]: Mismatch src(y=0,h=1),<br>
> dst(y=0,h=25), dy=0<br>
><br>
><br>
> No MMU faults, no screen corruptions.<br>
><br>
<br>
</span>The GPUs on MY6Q are unable to produce MMU faults, so with incorrect<br>
programming they are reading/writing unrelated data, or the MMU scratch<br>
page.<br>
<span><br>
<br>
> The imx6qp always have MMU faults and is showing the issues when<br>
> removing the "goto callback" instruction.<br>
> Aug 30 18:41:32 picolo etnaviv[1722]: Mismatch src(y=0,h=24),<br>
> dst(y=0,h=25), dy=0<br>
> Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=24),<br>
> dst(y=-25,h=25), dy=25<br>
> Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=1),<br>
> dst(y=-25,h=25), dy=1<br>
> Aug 30 18:41:41 picolo etnaviv[1722]: Mismatch src(y=0,h=1),<br>
> dst(y=0,h=25), dy=0<br>
<br>
</span>The MX6QP is much stricter on the MMU side and will stop the GPU from<br>
processing any further commands if it is trying to read/write unmapped<br>
data.<br>
<span><br>
><br>
> This probably indicates that there is no implementation issue with<br>
> CopyNtoN and this is rather a side effect of the MMU faults.<br>
><br>
<br>
</span>This indicates there is in fact an implementation error in CopyNtoN, but<br>
as Russell pointed out it seems to be caused by core X server functions.<br>
The question is if we can reasonably work around the issue.<br>
<br>
Regards,<br>
Lucas<br>
<br></blockquote><div> </div></div></div></div>Thanks for the clarification.</div><div class="gmail_extra">I will have a look at the X server APIs that Russell is referring to... and check the CopyNToN implementation.</div><div class="gmail_extra">Maybe I can find something, although I am not familiar with these APIs.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div>Luís</div>
</blockquote></div><br></div>