Summary: | Dies on vt switch | ||
---|---|---|---|
Product: | kmscon | Reporter: | beojan |
Component: | kmscon | Assignee: | David Herrmann <dh.herrmann> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | major | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
beojan
2014-03-24 13:28:47 UTC
Please compile kmscon with --enable-debug and run it with --debug so I can see a debug-log. Furthermore, if kmscon crashes, I _really_ need the backtrace/coredump. If you run systemd, you can use 'systemd-coredumpctl gdb kmscon' and then "bt" to get a gdb backtrace. If kmscon is started manually (e.g. with --debug), switching away then back freezes the system (i.e. if I switch to X and back, it freezes on my desktop), and requires a reboot. Also, Debian doesn't seem to include the systemd-coredumpctl tool. Is there any other way of getting a coredump. Few notes: * does kmscon freeze if you switch to an unused VT and back to kmscon? If not, please do that with --debug and provide the log * how do you run kmscon? Please show me the exact command-line arguments (and kmscon.conf in case you created one) * What graphics driver do you use? What graphics driver do you use with X? Proprietary drivers (nvidia, fglrx)? * How do you start up kmscon? Via systemd service-files? Does the same happen if you disable the service files and run kmscon via command-line? * Please try running kmscon with --no-drm and --no-hwaccel * Please try hard to get a backtrace for the crashed kmscon. If you know ssh and gdb, please try to login via ssh from another pc and run "gdb kmscon <pid>" to attach gdb to kmscon and run "backtrace" to get a stack-trace Strangely, it freezes if I switch to a kmscon vt with gdb attached. Anyhow, it's a segfault in libEGL.so.1, so likely not a kmscon bug. I'll see if I can attach a backtrace anyway. Ah yes, if you attach gdb, then it will block the VT switch. Please don't do that! Either attach gdb via ssh or make it read the core-dump afterwards. If the crash is in libEGL, please use --no-hwaccel, this will avoid any EGL calls. I meant attach gdb from ssh. Running kmscon again from gdb allows me to regain control. Backtrace is below: Program received signal SIGSEGV, Segmentation fault. 0x00000037af2177d4 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1 (gdb) backtrace #0 0x00000037af2177d4 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1 #1 0x00000037af209886 in eglSwapBuffers () from /usr/lib/x86_64-linux-gnu/libEGL.so.1 #2 0x000000000042286c in display_swap (disp=0x70d390, immediate=<optimized out>) at src/uterm_drm3d_video.c:303 #3 0x00000000004258a4 in uterm_drm_video_hotplug (video=video@entry=0x70cf00, read_dpms=read_dpms@entry=true, modeset=modeset@entry=true) at src/uterm_drm_shared.c:707 #4 0x0000000000425abf in uterm_drm_video_wake_up (video=video@entry=0x70cf00) at src/uterm_drm_shared.c:743 #5 0x000000000042377d in video_wake_up (video=0x70cf00) at src/uterm_drm3d_video.c:552 #6 0x000000000041971b in uterm_video_wake_up (video=0x70cf00) at src/uterm_video.c:682 #7 0x0000000000411641 in app_seat_event (s=<optimized out>, event=<optimized out>, data=0x649920) at src/kmscon_main.c:98 #8 0x000000000040dca7 in seat_go_foreground (seat=0x6499a0, force=<optimized out>) at src/kmscon_seat.c:191 #9 0x000000000040de5f in seat_run (seat=seat@entry=0x6499a0) at src/kmscon_seat.c:303 #10 0x000000000040e0a8 in seat_run (seat=0x6499a0) at src/kmscon_seat.c:292 #11 seat_vt_event (vt=<optimized out>, ev=<optimized out>, data=0x6499a0) at src/kmscon_seat.c:548 #12 0x000000000041b701 in vt_call (vt=vt@entry=0x66d4c0, event=event@entry=0, target=<optimized out>, force=force@entry=false) at src/uterm_vt.c:106 #13 0x000000000041bdc5 in vt_call_activate (vt=0x66d4c0) at src/uterm_vt.c:136 #14 real_sig_enter (info=<optimized out>, vt=0x66d4c0) at src/uterm_vt.c:212 #15 vt_sigusr1 (eloop=<optimized out>, info=<optimized out>, data=0x66d4c0) at src/uterm_vt.c:733 #16 0x000000000041421a in shl_hook_call (arg=0x7fffffffcff0, parent=0x648d80, hook=0x64f960) at src/shl_hook.h:223 #17 shared_signal_cb (fd=fd@entry=0x64cf20, mask=<optimized out>, data=<optimized out>) at src/eloop.c:376 #18 0x000000000041469a in ev_eloop_dispatch (loop=loop@entry=0x648d80, timeout=timeout@entry=-1) at src/eloop.c:873 #19 0x0000000000414e22 in ev_eloop_run (loop=0x648d80, timeout=timeout@entry=-1) at src/eloop.c:928 #20 0x0000000000407f79 in main (argc=<optimized out>, argv=0x7fffffffd328) at src/kmscon_main.c:632 (gdb) Yepp, that looks like a mesa bug. Can you answer the other questions I posted? In particular, does --no-hwaccel work around the bug? What driver do you use (radeon? and in particular, what version of kmscon, mesa and the kernel)? I fixed a bug regarding VT switches with radeon+mesa recently, so does this still happen with kmscon-git? I'm using the intel driver. kmscon-git with mesa 10.1 and kernel 3.12.0 --no-hwaccel works git doesn't seem to have been updated since November (git://people.freedesktop.org/~dvdhrm/kmscon) Yeah, there hasn't been anything spectacular since November. But the bug back then was specific to radeon. If you use kmscon-git, you get the EGL-reinit for free. If you want, you can try using "kmscube" by Rob-Clark, or the weston reference compositor and see whether they crash on VT switches either. But I recommend using --no-hwaccel (which actually should be the default?), as all that GL stuff is really Xorg specific and it's a pity no-one tests their code with anything else. I end up adding quirks for each new mesa version because they silently break the semantics.. If you could install debug symbols for mesa (afaik debian calls that the mesa-debug package), I could submit the EGL backtrace to Intel devs. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.