X11 segfault in vivante driver kernel L3.10.17_1.0.2

[henriroosen]

We are facing a segfault when using X11 on i.MX6 in 16 bit depth. Please find below the xorg.conf. When changing DefaultDepth to 24, the segfault is not seen.

Please find below the stacktrace. The main problem is that gcoSURF_Lock() returns an invalid address. That address is where some library has it's read-only mapping. The memcpy uses that address and the segfault happens.

gcoSURF_Lock() is implemented in libGAL.so and there is no source code, so I cannot trace this any further. This is a critical failure in our system, so please help.

Any help is appreciated!

Thanks, Henri

--------------------------------------------------------------------------

xorg.conf:

--------------------------------------------------------------------------

Section "ServerLayout"

        Identifier     "X.org Configured"

        Screen      0  "Screen0" 0 0

EndSection

Section "Device"

    Identifier  "i.MX Accelerated Framebuffer Device"

    Driver      "vivante"

    Option      "fbdev"     "/dev/fb0"

    Option      "vivante_fbdev" "/dev/fb0"

    Option      "HWcursor"  "false"

EndSection

Section "ServerFlags"

    Option "BlankTime"  "0"

    Option "StandbyTime"  "0"

    Option "SuspendTime"  "0"

    Option "OffTime"  "0"

EndSection

Section "Screen"

        Identifier "Screen0"

        Device     "i.MX Accelerated Framebuffer Device"

        Monitor    "Monitor0"

        DefaultDepth 16

        SubSection "Display"

                Viewport   0 0

                Depth     16

        EndSubSection

        SubSection "Display"

                Viewport   0 0

                Depth     24

        EndSubSection

EndSection

--------------------------------------------------------------------------

stacktrace:

--------------------------------------------------------------------------

#0  memcpy () at ../ports/sysdeps/arm/memcpy.S:101

#1  0xb6ad4aa8 in DoneByVSurf (pDst=0x2f4f78, x=1966072, y=3100304, w=800, h=480, src=<optimized out>, src_pitch=1600) at vivante_exa/vivante_exa.c:285

#2  0xb6852e8c in exaHWCopyNtoN (pSrcDrawable=0x1e23d0, pDstDrawable=<optimized out>, pGC=<optimized out>, pbox=<optimized out>, nbox=<optimized out>, nbox@entry=1, dx=dx@entry=0, dy=dy@entry=0, reverse=reverse@entry=0, upsidedown=upsidedown@entry=0) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/exa/exa_accel.c:532

#3  0xb6852f74 in exaCopyNtoN (pSrcDrawable=0x0, pDstDrawable=0x1dfff8, pGC=0x0, pbox=0x1e23d0, nbox=1, dx=0, dy=0, reverse=0, upsidedown=0, bitplane=0, closure=0x0) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/exa/exa_accel.c:582

#4  0x0014cdf4 in miCopyRegion (pSrcDrawable=pSrcDrawable@entry=0x1e23d0, pDstDrawable=pDstDrawable@entry=0x1dfff8, pGC=0x0, pGC@entry=0x1dfc30, pDstRegion=pDstRegion@entry=0xbefffaac, dx=dx@entry=0, dy=0, dy@entry=1, copyProc=0xb6852ecc <exaCopyNtoN>, copyProc@entry=0x0, bitPlane=bitPlane@entry=0, closure=0x0, closure@entry=0xb6852ecc <exaCopyNtoN>) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/mi/micopy.c:121

#5  0x0014d40c in miDoCopy (pSrcDrawable=0x1e23d0, pDstDrawable=0x1dfff8, pGC=0x1dfc30, xIn=0, yIn=yIn@entry=0, widthSrc=widthSrc@entry=800, heightSrc=heightSrc@entry=480, xOut=xOut@entry=0, yOut=yOut@entry=0, copyProc=0xb6852ecc <exaCopyNtoN>, bitPlane=0, closure=0x0) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/mi/micopy.c:297

#6  0xb68512c4 in exaCopyArea (dsty=0, dstx=0, height=480, width=800, srcy=0, srcx=<optimized out>, pGC=<optimized out>, pDstDrawable=<optimized out>, pSrcDrawable=<optimized out>) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/exa/exa_accel.c:608

#7  exaCopyArea (pSrcDrawable=0x1e23d0, pDstDrawable=0x1dfff8, pGC=0x1dfff8, srcx=0, srcy=0, width=800, height=480, dstx=0, dsty=0) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/exa/exa_accel.c:598

#8  0x000fdcd8 in damageCopyArea (pSrc=0x1e23d0, pDst=0x1dfff8, pGC=0x1dfc30, srcx=0, srcy=0, width=800, height=480, dstx=0, dsty=0) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/miext/damage/damage.c:825

#9  0x00032a50 in ProcCopyArea (client=0x1dfd60) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/dix/dispatch.c:1626

#10 0x00036810 in Dispatch () at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/dix/dispatch.c:432

#11 0x000261d8 in main (argc=1, argv=0x261d8 <main+1020>, envp=<optimized out>) at /home/user/yocto-kernel-3.10/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/xserver-xorg/2_1.14.0-r8.1/xorg-server-1.14.0/dix/main.c:295

[jamesbone]

From the trace, x=1966072, y=3100304 looks weird, it lools so big, I don't know where it is on the screen with w and h are 800 and 480.

The xorg.conf looks different than we generally used,  From xorg.config.man of xserver open source, it states,

subsection is to be used for Dispay:.

This entry is only needed when providing depth 24 configurations that allow

a choice between a 24 bpp packed framebuffer format and a 32bpp sparse

framebuffer format. In most cases this entry should not be used.

And

the "ViewPort " x0, y0,:

This optional entry sets the upper left corner of the initial display.

This is only relevant when the virtual screen resolution is different

from the resolution of the initial video mode.

If this entry is not given, then the initial display will be centered in

the virtual display area.

I guess this may be the reason why you got unreasonable x and y in the trace for 16 bit case

Maybe you can try when DefaultDepth 16 case

Section "Screen"

        Identifier "Screen0"

        Device     "i.MX Accelerated Framebuffer Device"

        Monitor    "Monitor0"

        DefaultDepth 16

EndSection

Hope this helps

[henriroosen]

Thanks for your reply. I tried your suggestion and unfortunately it didn't behave any different.

Note that the same application has been running fine on a 3.0.35 based iMX6 platform. We need to transition to 3.10 because we need hardware display rotation of 90 and 270 degrees and multitouch.

I found out this particular crash is because we are using XServer Shared-Memory Images and Pixmaps because the 3.10 based drivers report that capability. When disabling the use of XServer Shared-Memory, the system seems to be running a little longer, but will still crash.

Also note that we had to limit the amount of memory for the graphics drivers. The 320MB CMA :smileyalert: memory and the hardcoded 128MB galcore memory is way too much for our system which has only 256MB . Do you know if there a way to calculate the amount of memory needed? Currently I configured 32MB using the kernel commandline parameters for the galcore driver.

Any suggestions how to trace the issue further?

[jamesbone]

Your x and y are not reasonable, too big, they should not be larger than width and height(400, 800).  I don't know how your application pass this value to exa driver.

you can either configure the size of memory in kernel boot configuration file or by boot command. You can also use gmem_info tool to check the memory

[henriroosen]

We've now updated to the imx-3.10.53-1.1.0_ga release. This seems to be much more stable regarding graphics.

However, we still get Xserver crashes in libGAL.so: after starting the Xserver, our application uses XOpenDisplay()/XCloseDisplay() to detect whether the Xserver has started. When XOpenDisplay() succeeds then a call to XCloseDisplay() makes the Xserver crash, somewhere in libGAL.so. This is because the Xserver resets it's drivers on disconnect of the last client.

We can workaround this by starting the Xserver with the -noreset option.

To reproduce:

1) start /usr/bin/Xorg, no parameters and no window manager or other application

2) run the program below (waitforx)

3) Xserver crashes (segfaults)

/*

* Compile: cc -o waitforx waitforx.c -lX11

*/

#include <X11/Xlib.h>

int main(void)

{

        Display *xd = NULL;

        char *displayNum = ":0";

        if ((xd = XOpenDisplay(displayNum))) {

                XCloseDisplay(xd);

                return 1;

        }

        return 0;

}

[jamesbone]

Using 3.10.53 ga release, I cannot reproduce the crash when running your program. I tried both your way and

killall matchbox-window-manager

They all are running ok, no segmentation fault.

By the way, to change the gpu memory, you can change

chingling

[johannobermayr]

Hello,

now we use VLC mediaplayer library in our Project on kernel 3.0.35. and we see same error.

on Windows size 300x200 it work.

but with 800x600 it crash like the same Position as the callstack from Henri roosen.

in the file vivante_exa.c function: VivUploadToScreen there is a different on copy size.

it seem that it Crash on using DoneByVSurf.

and it work, wen it use the function DoneBySWCPY.

best regards

  Johann