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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux