<div dir="ltr"><div><div>Ok! Thanks! </div> </div>I'll have a look into that and will report once I have news. </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Oct 31, 2017 at 10:04 AM, Russell King - ARM Linux <<a href="mailto:linux@armlinux.org.uk" target="_blank">linux@armlinux.org.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 31, 2017 at 09:11:37AM +0000, Luís Mendes wrote: > Hi, > > 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. > 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. I haven't looked at the kernel etnaviv driver in detail for a while, but I added support for devcoredump to the driver, which dumps all buffers attached to the GPU. This is rigged up to recover_worker(). When a MMU exception occurs, you'd need to call a worker to take gpu->lock, and then call etnaviv_core_dump() in the same way recover_worker() does. You'll need to clone and install git://<a href="http://git.armlinux.org.uk/~rmk/etna-gpu-tools.git/" rel="noreferrer" target="_blank">git.armlinux.org.uk/~rmk/etna-gpu-tools.git/</a> which contains the udev rules to detect when an etnaviv coredump happens, and automatically unpack it. It'll want the etna_viv source for some of the tools, and you'll need to edit the Makefile to point it to that (it currently uses /shared/etna_viv). The devcoredump files will be located (by default) in /var/crash, named etnaviv-$date.bin, and the unpacked versions in /tmp/etnaviv-$date. Located in the package are tools to diff between two command streams, detile etnaviv buffers, a replacement viv_info utility for the DRM etnaviv version, and some scripts to help hexdump the MMU and 3D GPU index buffers. What I've omitted from it is the perl script I use to parse the GPU command stream - I forget why, but probably because it was rather dirty, and accessed memory via /dev/mem. I also don't think it had the bits for the 2D GPU. I'll see if I can clean it up at some point and include it in the above git tree. -- RMK's Patch system: <a href="http://www.armlinux.org.uk/developer/patches/" rel="noreferrer" target="_blank">http://www.armlinux.org.uk/developer/patches/</a> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to <a href="http://speedtest.net" rel="noreferrer" target="_blank">speedtest.net</a>: 8.21Mbps down 510kbps up </blockquote></div> </div>