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