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

Primoz Fiser primoz.fiser at norik.com
Mon Apr 26 10:21:55 UTC 2021


Hi all,

we are still affected by this issue from 2019 on 5.10.

For example when setting "cma=256M" on phycore imx6q with 2G ram we get:

> [   12.573276] etnaviv etnaviv: command buffer outside valid memory window
> [   12.616460] etnaviv etnaviv: command buffer outside valid memory window
> [   12.662517] etnaviv etnaviv: command buffer outside valid memory window
> [   12.714859] etnaviv etnaviv: command buffer outside valid memory window

On the other hand, when we set "cma=128M" this doesn't happen.

For now, we were able to get around this issue by applying Lucas' patches:

> "[PATCH 1/2] mm: cma: export functions to get CMA base and size"
> "[PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset 
> if possible"

However those didn't get accepted into mainline?

Has there been any progress on this?

Any tips on how to properly fix this in mainline?

BR,

Primoz


> 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