dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [REGRESSION] drm/etnaviv: command buffer outside valid memory window
@ 2019-06-22 16:16 Russell King - ARM Linux admin
  2019-06-27  9:20 ` Lucas Stach
  0 siblings, 1 reply; 7+ messages in thread
From: Russell King - ARM Linux admin @ 2019-06-22 16:16 UTC (permalink / raw)
  To: Fabio Estevam, l.stach, christian.gmeiner; +Cc: etnaviv, dri-devel

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

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 used to work, so its a regression.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: [REGRESSION] drm/etnaviv: command buffer outside valid memory window
@ 2021-04-26 10:21 Primoz Fiser
  0 siblings, 0 replies; 7+ messages in thread
From: Primoz Fiser @ 2021-04-26 10:21 UTC (permalink / raw)
  To: dri-devel; +Cc: linux

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-26 11:08 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-22 16:16 [REGRESSION] drm/etnaviv: command buffer outside valid memory window Russell King - ARM Linux admin
2019-06-27  9:20 ` Lucas Stach
2019-06-27 10:04   ` Russell King - ARM Linux admin
2019-06-27 14:32     ` Russell King - ARM Linux admin
2019-06-27 14:49       ` Lucas Stach
2019-06-27 16:48         ` Russell King - ARM Linux admin
2021-04-26 10:21 Primoz Fiser

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).