[REGRESSION] drm/etnaviv: command buffer outside valid memory window

Lucas Stach l.stach at pengutronix.de
Thu Jun 27 09:20:15 UTC 2019


Am Samstag, den 22.06.2019, 17:16 +0100 schrieb Russell King - ARM Linux admin:
> While updating my various systems for the TCP SACK issue, I notice
> that while most platforms are happy, the Cubox-i4 is not.  During
> boot, we get:
> 
> [    0.000000] cma: Reserved 256 MiB at 0x30000000
> ...
> [    0.000000] Kernel command line: console=ttymxc0,115200n8 console=tty1 video=mxcfb0:dev=hdmi root=/dev/nfs rw cma=256M ahci_imx.hotplug=1 splash resume=/dev/sda1
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [    0.000000] Memory: 1790972K/2097152K available (8471K kernel code, 693K rwdata, 2844K rodata, 500K init, 8062K bss, 44036K reserved, 262144K cma-reserved, 1310720K highmem)
> ...
> [   13.101098] etnaviv-gpu 130000.gpu: command buffer outside valid memory window
> [   13.171963] etnaviv-gpu 134000.gpu: command buffer outside valid memory window

Yes, that's a regression due to different default CMA area placement
and etnaviv not being smart enough to move the linear window to the
right offset.

Patches to fix this (but have rightfully been shot down, due to
layering violations) are "[PATCH 1/2] mm: cma: export functions to get
CMA base and size" and "[PATCH 2/2] drm/etnaviv: use CMA area to
compute linear window offset if possible".

> and shortly after the login prompt appears, the entire SoC appears to
> lock up - it becomes unresponsive on the network, or via serial console
> to sysrq requests.
> 
> I suspect the GPU ends up scribbling over the CPU's vector page/kernel
> as a result of the above two etnaviv errors when Xorg attempts to start
> using the GPU.

This should not be possible. The driver notices that the command buffer
isn't accessible to the GPU, which aborts the GPU init. While the
etnaviv DRM device is still accessible, it will not expose any
enumerable GPU cores to userspace. So there is no way for userspace to
actually submit GPU commands.

Regards,
Lucas


More information about the dri-devel mailing list