Re: [PATCH] drm/etnaviv: rework linear window offset calculation
Hi Lucas, we tested your patch on PHYTEC i.MX6Q phyCORE with 1GiB and 2GiB RAM variants. I can happily report that the previous issues with "command buffer outside valid memory window" are gone when using kernel's cmdline parameter cma=256M for example! If you want you can add: Tested-by: Primoz Fiser Otherwise, thank you for prompt response and implemented fix. BR, Primoz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset if possible
Hi, what happened to these patches? In thread "[REGRESSION] drm/etnaviv: command buffer outside valid memory window" [1] it was mentioned these got "shot down" due to layering violations, but no official correspondence has been found? Is is due to exporting symbols from mm/cma.c in [1/2] and why is this an issue? We are still affected by issue these patches tried to address and we are interested in getting the solution into mainline. Patches were integrated (small fix required due to renamed include file header) and tested on latest master with PHYTEC's 2GiB phyCORE SoM and cma=256M kernel cmdline parameter. Without patches: [7.892954] etnaviv etnaviv: bound 13.gpu (ops gpu_ops) [7.901286] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) [7.909809] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) [7.915775] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108 [7.924000] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [7.930615] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 [7.936934] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 [7.948600] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1 [ 16.656092] etnaviv etnaviv: command buffer outside valid memory window [ 16.695777] etnaviv etnaviv: command buffer outside valid memory window [ 16.765654] etnaviv etnaviv: command buffer outside valid memory window [ 16.800111] etnaviv etnaviv: command buffer outside valid memory window NOTE: See "command buffer outside valid memory window" errors when trying to use GPU. With patches: [7.708159] etnaviv etnaviv: bound 13.gpu (ops gpu_ops) [7.716095] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) [7.724257] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) [7.730205] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108 [7.738407] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [7.745039] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 [7.751365] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 [7.762876] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 1 NOTE: No errors, GPU fully functional! In the end, it looks like we are not the only ones with the same issues as patch "drm/etnaviv: optionally set gpu linear window to cma area" that addresses the same issue was submitted by Sven Van Asbroeck (see [2]). Unfortunately, his solution was also not accepted. Please advise what would be the best solution implementation and how to proceed in this case? BR, Primoz [1] https://lists.freedesktop.org/archives/dri-devel/2019-June/223516.html [2] https://lore.kernel.org/dri-devel/20190619183856.467-1-thesve...@gmail.com/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] drm/etnaviv: command buffer outside valid memory window
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.00] cma: Reserved 256 MiB at 0x3000 />/... />/[0.00] 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.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) />/[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) />/[0.00] 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 13.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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
