Address check for command buffer, etnaviv on Novena

Lucas Stach l.stach at pengutronix.de
Wed Nov 1 13:45:47 UTC 2017


Hi Jan,

Am Mittwoch, den 01.11.2017, 11:47 +0100 schrieb Jan Binder:
> Hello,
> 
> I am trying to get kernel 4.14-rc6 to run on my Novena imx6q board
> with Debian experimental and Mesa 17.3.0-rc2 and ran into some
> problems with 
> etnaviv complaining about "command buffer outside valid memory
> window".
> 
> I have a 256MB CMA allocation area set up at 0x70000000 in my 
> devicetree.

Please don't use fixed addresses for the CMA region. Etnaviv works fine
as long as you allow the kernel to work out the CMA address on its own.

Regards,
Lucas

> While investigating how the buffer gets allocated at > 0x80000000,
> I found the following suspicious part of a commit changing the
> address 
> check:
> 
> commit c3ef4b8c3e108397980014a4616c56f50026d547
> drm/etnaviv: wire up iova handling in new cmdbuf abstraction
> 
> @@ -703,7 +703,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>          }
> 
>          if (gpu->mmu->version == ETNAVIV_IOMMU_V1 &&
> -           gpu->buffer->paddr - gpu->memory_base > 0x80000000) {
> +           etnaviv_cmdbuf_get_va(gpu->buffer) > 0x80000000) {
>                  ret = -EINVAL;
>                  dev_err(gpu->dev,
>                          "command buffer outside valid memory
> window\n");
> 
> 
> The implementations of in etnaviv_cmdbuf.c suggest that
> etnaviv_cmdbuf_get_pa should be used to check physical addresses like
> before the commit:
> 
> u32 etnaviv_cmdbuf_get_va(struct etnaviv_cmdbuf *buf)
> {
> 	return buf->suballoc->iova + buf->suballoc_offset;
> }
> 
> dma_addr_t etnaviv_cmdbuf_get_pa(struct etnaviv_cmdbuf *buf)
> {
> 	return buf->suballoc->paddr + buf->suballoc_offset;
> }
> 
> The values returned by etnaviv_cmdbuf_get_va are typically >
> 0xf0000000 
> on my system, while etnaviv_cmdbuf_get_pa always returns a value
> between
> 0x70000000 and 0x80000000.
> 
> If I change etnaviv_cmdbuf_get_va to etnaviv_cmdbuf_get_pa, the
> address 
> check
> obviously passes, but I get gpu hangs.
> 
> I can either hang the GC320 unit starting X with xf86-video-armada:
> 
> [  189.026916] etnaviv-gpu 134000.gpu: hangcheck detected gpu lockup!
> [  189.028946] etnaviv-gpu 134000.gpu:      completed fence: 29
> [  189.030984] etnaviv-gpu 134000.gpu:      active fence: 34
> [  189.033059] etnaviv-gpu 134000.gpu: hangcheck recover!
> 
> or the GC2000 unit when starting the Weston wayland compositor:
> 
> [  580.116792] etnaviv-gpu 130000.gpu: hangcheck detected gpu lockup!
> [  580.116840] etnaviv-gpu 130000.gpu:      completed fence: 13
> [  580.116855] etnaviv-gpu 130000.gpu:      active fence: 14
> [  580.116893] etnaviv-gpu 130000.gpu: hangcheck recover!
> 
> Either way, I get a black screen and no other error indications than
> the dmesg 
> messages.
> 
> I would love to hear your suggestions.
> 
> Jan Binder
> _______________________________________________
> etnaviv mailing list
> etnaviv at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv


More information about the etnaviv mailing list