Hi,
I'm using the iMX6 SoloX SABRE board with Framebuffer backend (no X11) and encountered an issue during developing an EGL application.
The following, rather simple, test-application crashes (see attached eglinitialize-bug.c for full source) with a kernel panic (see attached kernel-panic.txt).
int main(int argc, char **argv)
{
EGLNativeWindowType native_window;
EGLNativeDisplayType native_display;
mlockall(MCL_CURRENT | MCL_FUTURE);
native_display = fbGetDisplayByIndex(0);
native_window = fbCreateWindow(native_display, 0, 0, 0, 0);
printf("Before eglGetDisplay\n");
// The following call produces kernel panic if mlockall(MCL_FUTURE) has been called
eglGetDisplay(native_display);
printf("After eglGetDisplay\n");
return 0;
}
Excerpt of the kernel panic:
[<800b8054>] (remap_pfn_range) from [<80018928>] (arm_dma_mmap+0xc8/0xcc)
[<80018928>] (arm_dma_mmap) from [<804b3938>] (gckOS_MapMemory+0x18c/0x224)
[<804b3938>] (gckOS_MapMemory) from [<804b93b8>] (drv_open+0xb4/0x158)
[<804b93b8>] (drv_open) from [<800d8a5c>] (chrdev_open+0xa4/0x178)
If I remove the call of mlockall in the application, the kernel panic does not happen. Unfortunately, in my real use-case, the function mlockall is called by a close-sourced framework we are using, i.e. I cannot modify that. According to the stack trace, the Vivante driver seems to be the culprit, or is at least involved.
Is this intended or a known bug? Why does the Vivante GPU-driver crash or cause a crash in this situation?
I'm using 3.14.28 and also have tried with 3.14.38.
I'm cross-compiling (with Yocto toolchain) the .c file with:
$(CC) -o eglinitialize-bug eglinitialize-bug.c -DLINUX -DEGL_API_FB -lc -lEGL
Original Attachment has been moved to: eglinitialize-bug.c.zip
Original Attachment has been moved to: kernel-panic.txt.zip
Any suggestions by Freescale or a Vivante GPU expert on this bug?
Hi JohnDoe1z
Actually I think this is an issue with mlockall function in this kernel version, since when given the MCL_FUTURE flag, is supposed to cause all future memory allocations in that process to become wired. However, memory obtained from the mmap() function was not being wired correctly after using mlockall(). This results in low performance from the mmap memory pages. This function should be use only on small processes, because all memory pages of the process will be locked into memory code, data and libraries, i guess this is the reason of kernel panic. I do not suggest to be used with GPU driver, if you like to swap contexts you can use eglswapbuffers or any egl functions
Hope this helps