[galcore]: Stop driver to keep scene.


  • Board: ArmStoneA9r2 rev1.20

    CPU: IMX6-DualLite

    Build: fsimx6B2020.04

    Hi,

    I'm running a Qt application with default platform settings (EGLFS). After few hours, the application UI is frozen but the application is still running.
    The output of dmesg contains the error [galcore]: Stop driver to keep scene and some memory dump. During this , free memory from the command free has reached to 4MB.

    Help me solve this issue.


  • Unfortunately we can not decode this error message, too. The display driver including the GPU part is only partly available in source code in the Linux kernel, a big part of it is closed source and only available as binary libraries in the root filesystem.


    But the hint about the free memory sounds interesting. Do you still have the output of the free command from this case? Is it really only 4 MB of free RAM? Sometimes the output is misleading, as most free memory is used for the buffer cache to speed up file accesses. But such cache can be counted as free memory. When memory is needed, the least recently used pages from the buffer cache are simply thrown away and can be used for the new memory request.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • As I already assumed, 65MB of memory are used by the buffer cache and 62MB of it are still available as free memory. So I would say the system was not out of memory when this happened. At least not out of regular memory. There are other cases where memory may still have been short. For example there is the CMA region (Continuous Memory Allocator). Normal memory is allocated using the paging mechanism. So an arbitrary page in memory can be used and it is given a virtual address so that it can be part of a larger continuous memory region allocated by malloc() for example. But it is only continuous in the virtual address space. On the physical address space, it can be arbitrarily fragmented. Theoretically each page can be located somewhere else in physical memory and still the virtual addresses show one continuous region.


    The CMA region is different. Here also the physical address region has to be continuous. This is needed when the region is accessed by DMA, where the DMA only sees the physical addresses. So for example a (frame) buffer that can be shown on the display needs to be a continuous memory region in the physical address space, too, so that the display controller can send the data to the display via DMA. If the CMA region is exhausted or very fragmented, maybe the display driver can not allocate any large enough buffers anymore and will get into such a non-standard state. But this is just a guess.


    Maybe the CMA debugfs can be useful to prove or disprove this.


    https://www.kernel.org/doc/htm…guide/mm/cma_debugfs.html


    If allocating (and freeing) a large block via debugfs works with a newly started system, but fails to work on a system that is running for many hours, than this could be an indication for the CMA running out of continuous memory.


    If this is actually the case, it may be your application or Qt that may be responsible. Probably there is a memory leak, some buffer that is allocated from time to time but never freed, causing the CMA pool to get more and more fragmented, so that at some point of time it is not possible anymore to allocate a rather large continuous memory block required for the display driver.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.