[yocto] Xorg failing with SEGV after Krogoth update
Allan Chandler
allan.chandler at dti.com.au
Sun Jul 3 19:38:16 PDT 2016
Khem,
I managed to get gdb up and running on the target system by adding 'tools-debug' to the 'IMAGE_FEATURES' in my top level recipe, executing 'ulimit -c unlimited' as you suggested, and running 'Xorg -core'.
I'll start looking into it more deeply but initial investigation seems to indicate something has smashed the stack. Loading up the core file for a backtrace gives me:
Core was generated by `Xorg -br -pn -nolisten tcp -core'.
Program terminated with signal SIGABRT, Aborted.
#0 0x76afda54 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x76afda54 in raise () from /lib/libc.so.6
#1 0x76afedd0 in abort () from /lib/libc.so.6
#2 0x00183708 in OsAbort ()
#3 0x0007e6c0 in ddxGiveUp ()
#4 0x001887ac in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Not _overly_ useful information since, by the time you're in ddxGiveUp, you're already well and truly into the abort process. Still, it's a good starting point, so I'm appreciative of your assistance.
If anyone else also wants to weigh in with their advice (or even at least relatively intelligent speculation), I'd be grateful.
Cheers,
Al.
-----Original Message-----
From: Khem Raj [mailto:raj.khem at gmail.com]
Sent: Friday, 1 July 2016 11:02 PM
To: Allan Chandler
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] Xorg failing with SEGV after Krogoth update
On Thu, Jun 30, 2016 at 10:24 PM, Allan Chandler <allan.chandler at dti.com.au> wrote:
> We recently did (attempted? ) an upgrade of our Yocto embedded build
> system from Fido to Krogoth and, other than one rather massive issue,
> it all went well.
>
>
>
> The massive issue is the fact that X11 is apparently not starting
> correctly. The embedded device boots okay since we can see in via a
> serial console as well as connecting via SSH.
>
>
>
> We've narrowed the actual issue down to the Xorg executable, after
> following the process the the rc5.d Xserver satrtup scripts and xinit
> - basically, Xorg is dumping core with the following output:
>
may be you can enable coredump and collect it for offline post mortem setting ulimit -c unlimited e.g. when you run the suspected program will dump it
>
>
> X.Org X Server 1.18.0
>
> Release Date: 2015-11-09
>
> X Protocol Version 11, Revision 0
>
> Build Operating System: Linux 3.19.0-25-generic x86_64
>
> Current Operating System: Linux imx6 3.14.28+g2b0ab6d #1 SMP
> PREEMPT Thu Jun 30 12:20:09 AWST 2016 armv7l
>
> Kernel command line: console=ttymxc0,115200 consoleblank=0
> root=/dev/mmcblk3p2 rootwait
>
> Build Date: 30 June 2016 01:38:24PM
>
>
>
> Current version of pixman: 0.32.8
>
> Before reporting problems, check
> https://linkprotect.cudasvc.com/url?a=http://wiki.x.org&c=E,1,4NSJpdkB
> 74woeWCSgwq2yLsnPqo_Nw27PMKnrxE-_x_0DAqZF5Z0WYcmV4NJ1-ni3fjHphEzkRgcSt
> 4Gfm-gPUcpYnS2hfj-TM3SeZPx&typo=1
>
> to make sure that you have the latest version.
>
> Markers: (--) probed, (**) from config file, (==) default setting,
>
> (++) from command line, (!!) notice, (II) informational,
>
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jul 1 00:12:43
> 2016
>
> (==) Using config file: "/etc/X11/xorg.conf"
>
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>
> (==) No Layout section. Using the first Screen section.
>
> (==) No screen section available. Using defaults.
>
> (**) |-->Screen "Default Screen Section" (0)
>
> (**) | |-->Monitor "<default monitor>"
>
> (==) No device specified for screen "Default Screen Section".
>
> Using the first device section listed.
>
> (**) | |-->Device "i.MX Accelerated Framebuffer Device"
>
> (==) No monitor specified for screen "Default Screen Section".
>
> Using a default monitor configuration.
>
> (**) Option "BlankTime" "0"
>
> (**) Option "StandbyTime" "0"
>
> (**) Option "SuspendTime" "0"
>
> (**) Option "OffTime" "0"
>
> (==) Automatically adding devices
>
> (==) Automatically enabling devices
>
> (==) Automatically adding GPU devices
>
> (==) Max clients allowed: 256, resource mask: 0x1fffff
>
> (WW) The directory "/usr/share/fonts/X11/misc/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/TTF/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/OTF/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/Type1/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
>
> Entry deleted from font path.
>
> (==) FontPath set to:
>
>
>
> (==) ModulePath set to "/usr/lib/xorg/modules"
>
> (II) The server relies on udev to provide the list of input devices.
>
> If no devices become available, reconfigure udev or
> disable AutoAddDevices.
>
> (II) Loader magic: 0x1c3a20
>
> (II) Module ABI versions:
>
> X.Org ANSI C Emulation: 0.4
>
> X.Org Video Driver: 20.0
>
> X.Org XInput driver : 22.1
>
> X.Org Server Extension : 9.0
>
> (II) xfree86: Adding drm device (/dev/dri/card0)
>
> (II) no primary bus or device found
>
> falling back to /sys/devices/platform/Vivante
> GCCore/drm/card0
>
> (II) LoadModule: "glx"
>
> (II) Loading
> /usr/lib/xorg/modules/extensions/https://linkprotect.cudasvc.com/url?a
> =https://libglx.so&c=E,1,rWCTnmvxgKl3t1h9kzYR97U5p8_LorGwNnAPlzv5X-es4
> r-xPRI4JstYBa9v7OcbuW5I_1pfNpwnkrCb4cgoWjexyDb4c4ZMtBnLj8IMSSzvkCc,&ty
> po=1
>
> (II) Module glx: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 1.0.0
>
> ABI class: X.Org Server Extension, version 9.0
>
> (==) AIGLX enabled
>
> (II) LoadModule: "vivante"
>
> (II) Loading
> /usr/lib/xorg/modules/drivers/https://linkprotect.cudasvc.com/url?a=ht
> tps://vivante_drv.so&c=E,1,HPS9797dgBJCjHcEQVjXk5HrpUJ2Hv3bKn5vNK37VxB
> -huI7nFFv0Txhph1hkO9iKXsBShjJlqWbrI_v6JMmjcm_gwgc3yUg4pt3ocU7CmQsfdM,&
> typo=1
>
> (II) Module vivante: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 1.0.0
>
> Module class: X.Org Video Driver
>
> ABI class: X.Org Video Driver, version 20.0
>
> (II) VIVANTE: driver for vivante fb: VivanteGC500, VivanteGC2100,
>
> VivanteGCCORE
>
> (--) using VT number 3
>
>
>
> (WW) Falling back to old probe method for vivante
>
> (II) Loading sub module "fbdevhw"
>
> (II) LoadModule: "fbdevhw"
>
> (II) Loading
> /usr/lib/xorg/modules/https://linkprotect.cudasvc.com/url?a=https://li
> bfbdevhw.so&c=E,1,p8UUbTWdgyNhmM2x3ts0us_rbqKTo9NCwqOb_vQsannA3Liz2ERk
> HXFn8yZmnu3PisYFhk4cvhjOVUjKrI-BQUOoimXhkXTk4wDj3_vdwqmcxKs6X0BO&typo=
> 1
>
> (II) Module fbdevhw: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 0.0.2
>
> ABI class: X.Org Video Driver, version 20.0
>
> (II) VIVANTE(0): using default device
>
> (II) VIVANTE(0): Device preferred mode 'fb0':U:1024x768p-60
>
> (II) VIVANTE(0): Creating default Display subsection in Screen
> section
>
> "Default Screen Section" for depth/fbbpp 16/16
>
> (==) VIVANTE(0): Depth 16, (==) framebuffer bpp 16
>
> (==) VIVANTE(0): RGB weight 565
>
> (==) VIVANTE(0): Default visual is TrueColor
>
> (==) VIVANTE(0): Using gamma correction (1.0, 1.0, 1.0)
>
> (**) VIVANTE(0): Option "fbdev" "/dev/fb0"
>
> (II) VIVANTE(0): checking modes against framebuffer device...
>
> (II) VIVANTE(0): checking modes against monitor...
>
> (II) VIVANTE(0): Use built in mode (bpp 16)
>
> (--) VIVANTE(0): Virtual size is 0x0 (pitch 0)
>
> (==) VIVANTE(0): DPI set to (96, 96)
>
> (II) Loading sub module "fb"
>
> (II) LoadModule: "fb"
>
> (II) Loading
> /usr/lib/xorg/modules/https://linkprotect.cudasvc.com/url?a=https://li
> bfb.so&c=E,1,DQk14_zPgWGMzKa1n3_ZGjGM-3EYlxTjN85v-rUnqJo65a3idj3jrP5I0
> rxKe4srCKZVA8Xo9UhoMVy6bmTs9d-BuYDqcrOWda9aeMD7A1_ZWnQPlhTSqA,,&typo=1
>
> (II) Module fb: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 1.0.0
>
> ABI class: X.Org ANSI C Emulation, version 0.4
>
> (II) Loading sub module "exa"
>
> (II) LoadModule: "exa"
>
> (II) Loading
> /usr/lib/xorg/modules/https://linkprotect.cudasvc.com/url?a=https://li
> bexa.so&c=E,1,LnhTIA7F3Cahe2VCzeXBg989fKtHTL6htf5gZQcpV49NnuAOHR9W9Xkv
> H24yhgmab7IY9H-nor7c-wLP34fnNGkAkNEjro58GWqv1BaCITkkHFM6rg,,&typo=1
>
> (II) Module exa: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 2.6.0
>
> ABI class: X.Org Video Driver, version 20.0
>
> (II) VIVANTE(0): printing discovered frame buffer 'fb0' supported modes:
>
> (II) VIVANTE(0): Modeline "U:1024x768p-60"x0.0 65.00 1024 1064 1124
> 1344 768 775 785 806 -hsync -vsync -csync (48.4 kHz eP)
>
> (II) VIVANTE(0): Output DISP4 BG has no monitor section
>
> (II) VIVANTE(0): Printing probed modes for output DISP4 BG
>
> (II) VIVANTE(0): Modeline "U:1024x768p-60"x60.0 65.00 1024 1064 1124
> 1344 768 775 785 806 -hsync -vsync -csync (48.4 kHz eP)
>
> (II) VIVANTE(0): Output DISP4 BG connected
>
> (II) VIVANTE(0): Using exact sizes for initial modes
>
> (II) VIVANTE(0): Output DISP4 BG using initial mode U:1024x768p-60
> +0+0
>
> (II) VIVANTE(0): imxDisplayPreInit: virtual set 1024 x 768,
> display width 0
>
> (II) VIVANTE(0): FBDevPreInit: adjust display width 1024
>
> (**) VIVANTE(0): PreInit done
>
> (II) VIVANTE(0): Init mode for fb device
>
> (II) VIVANTE(0): hardware: DISP4 BG (video memory: 8164kB)
>
> (II) VIVANTE(0): FB Start = 0x75da6000 FB Base = 0x75da6000 FB
> Offset = (nil) FB PhyBase 0x3c500000
>
> (II) VIVANTE(0): reserve 4177920 bytes for on screen frame buffer;
> total fb memory size 8359936 bytes; offset of shadow buffer 4177920
>
> (II) VIVANTE(0): hardware: DISP4 BG (video memory: 8164kB)
>
> (WW) VIVANTE(0): FBIOPAN_DISPLAY: Invalid argument
>
> (II) VIVANTE(0): test Initializing EXA
>
> (EE)
>
> (EE) Backtrace:
>
> (EE)
>
> (EE) Segmentation fault at address 0xc
>
> (EE)
>
> Fatal server error:
>
> (EE) Caught signal 11 (Segmentation fault). Server aborting
>
> (EE)
>
> (EE)
>
> Please consult the The X.Org Foundation support
>
> at
> https://linkprotect.cudasvc.com/url?a=http://wiki.x.org&c=E,1,1qFFp2wQ
> jTx5KamLHZUk5dLQpwkZ8oeBvjczYGc3LNYM7BS-B3FC_L4ZDf4gDKmsoFVHVhQuDSBi0V
> valEa2FVif6qdylIQukJNP8W17vxOSSgQkAnc,&typo=1
>
> for help.
>
> (EE) Please also check the log file at "/var/log/Xorg.0.log" for
> additional information.
>
> (EE)
>
> (EE) Server terminated with error (1). Closing log file.
>
> Aborted
>
>
>
> You can see in the final dozen lines or so that it gets a SIGSEGV.
> I've searched for a solution online but the only close one I've
> discovered
> (https://linkprotect.cudasvc.com/url?a=https://community.nxp.com/thread/327339&c=E,1,VU7qIf5JWCJIY3Pma4-SL3erAc6j6V2vC3EESZu1N11ogjuSjqkds13f9gjBFlsvHNxuhhF_VOLu68VukyLTKLa5CJC0YgJ5u5M5ha0,&typo=1) is for a different error.
>
>
>
> For what it's worth, the working Fido variant is much the same (though
> with different version numbers for components, primarily Xorg 1.16.3)
> but it carries on after the "test Initializing EXA" line:
>
>
>
> [2750328.650] (II) VIVANTE(0): test Initializing EXA
>
> [2750328.650] (II) VIVANTE(0): (driver build from:
> f2cae50cf6c3c924be2e06c43c819cb23ca1bf5c)
>
> [2750328.654] (II) EXA(0): Driver allocated offscreen pixmaps
>
> [2750328.654] (II) EXA(0): Driver registered support for the
> following
> operations:
>
> [2750328.654] (II) Solid
>
> [2750328.654] (II) Copy
>
> [2750328.654] (II) Composite (RENDER acceleration)
>
> [2750328.654] (II) UploadToScreen
>
> [2750328.670] (II) VIVANTE(0): Init SHM pixmap support
>
> [2750328.670] (==) VIVANTE(0): Backing store enabled
>
> [2750328.673] (==) VIVANTE(0): DPMS enabled
>
> [2750328.673] (II) VIVANTE(0): RandR 1.2 enabled, ignore the
> following RandR disabled message.
>
> [2750328.674] drmOpenDevice: node name is /dev/dri/card0
>
> [2750328.674] drmOpenDevice: open result is 11, (OK)
>
> [2750328.674] drmOpenDevice: node name is /dev/dri/card0
>
> [2750328.674] drmOpenDevice: open result is 11, (OK)
>
> [2750328.674] drmOpenByBusid: Searching for BusID platform:Vivante
> GCCore:00
>
> [2750328.674] drmOpenDevice: node name is /dev/dri/card0
>
> [2750328.674] drmOpenDevice: open result is 11, (OK)
>
> [2750328.674] drmOpenByBusid: drmOpenMinor returns 11
>
> [2750328.674] drmOpenByBusid: drmGetBusid reports platform:Vivante
> GCCore:00
>
> [2750328.674] (II) [drm] DRM interface version 1.4
>
> [2750328.674] (II) [drm] DRM open master succeeded.
>
> [2750328.674] (II) VIVANTE(0): [drm] Using the DRM lock SAREA also
> for drawables.
>
> [2750328.674] (II) VIVANTE(0): [drm] framebuffer handle =
> 0x44700000
>
> [2750328.674] (II) VIVANTE(0): [drm] added 1 reserved context for
> kernel
>
> [2750328.674] (II) VIVANTE(0): X context handle = 0x1
>
> [2750328.675] (II) VIVANTE(0): [drm] installed DRM signal handler
>
> [2750328.675] (II) VIVANTE(0): [DRI] installation complete
>
> [2750328.675] (--) RandR disabled
>
> [2750328.702] (II) AIGLX: Screen 0 is not DRI2 capable
>
> [2750328.702] (EE) AIGLX: reverting to software rendering
>
> [2750328.751] (II) AIGLX: Loaded and initialized swrast
>
> [2750328.751] (II) GLX: Initialized DRISWRAST GL provider for
> screen 0
>
> [2750328.753] (II) VIVANTE(0): Setting screen physical size to 270
> x 203
>
>
>
> I'd appreciate any pointers on how best to debug/resolve this issue
> since I cannot appear to get any more detailed information out of
> `Xorg` itself. Or, alternatively, if anyone has seen this same (or
> very similar) problem, how was it solved?
>
>
>
> Cheers,
>
> Al.
>
>
>
> Allan Chandler | Software Engineer
>
> DTI Group Ltd | Transit Security & Surveillance
>
> 31 Affleck Road, Perth Airport, WA 6105, AU
>
> P | F | allan.chandler at dti.com.au
>
>
>
> Visit our website
> https://linkprotect.cudasvc.com/url?a=https://www.dti.com.au&c=E,1,Slv
> VI1qAkGlYaCP0zPet2HssUF_IAlDs1RkTCG2w7R8AWGV8rUCymcaIhnJcvthhwE_ENEjcy
> mpGpFUeqRCahWZkJp-fCHI9op2S6ji_K35xamlOAdmhlw,,&typo=1
>
> The information contained in this email is confidential. If you
> receive this email in error, please inform DTI Group Ltd via the above contact details.
> If you are not the intended recipient, you may not use or disclose the
> information contained in this email or attachments.
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://linkprotect.cudasvc.com/url?a=https://lists.yoctoproject.org/l
> istinfo/yocto&c=E,1,vbpvvaZVQHD70gaqaoB17XtNkHjXPMYix19oLQEXDqYsbOPOQYwhiTYPbc1raj6NTPG08obeo0uQOVNKd4LgqM_ueOd14WCiAdnBzQ,,&typo=1
>
More information about the yocto
mailing list