Kernel panic in eglGetDisplay

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kernel panic in eglGetDisplay

915 Views
JohnDoe1z
Contributor III

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

Labels (3)
0 Kudos
2 Replies

554 Views
JohnDoe1z
Contributor III

Any suggestions by Freescale or a Vivante GPU expert on this bug?

0 Kudos

554 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

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

0 Kudos