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

[Lucas Stach]

Am Dienstag, den 31.10.2017, 10:04 +0000 schrieb Russell King - ARM Linux:
> 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.

With the current page table settings for MMUv2 any MMU fault will
actually stall the GPU. This way faults will already trigger the
generation of coredumps, as the GPU is hung at that point. You don't
need to change anything in the kernel driver for this to work.

Regards,
Lucas

> You'll need to clone and install
> 
>   git://git.armlinux.org.uk/~rmk/etna-gpu-tools.git/
> 
> 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.
>