I have kmscon set up to start automatically on VT 2 - 6 through systemd. However, if I switch to a kmscon vt, switch away, then switch back, I find kmscon has died, and I am at the linux console.
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.
* 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
#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)
#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
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
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.