This is a somehow old topic, but I have spent the last days trying to find a solution for this:
[ 26.929682] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 26.936664] [drm] V3D: 51052kb BOs (46)
[ 26.943072] [drm] V3D shader: 56kb BOs (14)
[ 26.949460] [drm] dumb: 8148kb BOs (4)
[ 26.955729] [drm] total purged BO: 8236kb BOs (5)
[ 26.962034] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
I have not been able to find a real "recent" solution to this on google. The issue here is what "recent" means:
- Some fixes and posts about this are old (2018, old kernel, prior to dynamic CMA removal)
- Recent kernels should fix this ">5.x.x"
- Raspbian is in the middle.... (4.19)
So the solution:
Code: Select all
echo on >/sys/devices/platform/soc/*.v3d/power/control
I hope this saves some time to many people trying to get drm kms / fkms it to work without the rendering engine hanging a few minutes after booting...
(from looking for the error at the kernel source, and "tracing" back):
In this version of the kernel, the tile binning memory buffer is allocated when the device is loaded onto the kernel (good!) but it gets freed when the device goes into "runtime suspended" state. This is different from hibernating or suspending the system: this is the kernel putting specific devices in "runtime suspended" mode when not used for some time to save power.
So when the kernel wakes the device up again, there is a high probability that the driver will not find a new 16M contiguous
memory block available in the CMA area for the tile binning memory. Hence the error (and frozen rendering with rebooting being the only solution).
The solution, above, is forcing the drm device to be always "on", disabling automatic "runtime suspend" before it freezes
(so at boot).
In newer kernels, the tile binning memory block is allocated only when the first application requires tile binning memory, and freed when the last thread frees it (so the situation becomes worse
), but so far I found, as a workaround, to compile a small "daemon" that allocates 1 byte for tile binning, and immediately suspends forever, so the 16M block will never be freed, leaving most of it available for real apps using it. Let's see if still needed when raspbian gets to kernel 5.x.x...
I have changed part of the device name in the command above by a wildcard '*', as it seems the device name may vary between systems (or maybe pi models).