Bug 76553 - Dies on vt switch
Summary: Dies on vt switch
Alias: None
Product: kmscon
Classification: Unclassified
Component: kmscon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: David Herrmann
QA Contact:
Depends on:
Reported: 2014-03-24 13:28 UTC by beojan
Modified: 2014-03-27 20:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description beojan 2014-03-24 13:28:47 UTC
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.
Comment 1 David Herrmann 2014-03-24 13:35:14 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.
Comment 2 beojan 2014-03-24 14:59:41 UTC
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.
Comment 3 David Herrmann 2014-03-27 17:35:46 UTC
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
Comment 4 beojan 2014-03-27 17:48:21 UTC
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.
Comment 5 David Herrmann 2014-03-27 17:49:51 UTC
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.
Comment 6 beojan 2014-03-27 17:53:30 UTC
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
Comment 7 David Herrmann 2014-03-27 17:55:46 UTC
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?
Comment 8 beojan 2014-03-27 18:48:06 UTC
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)
Comment 9 David Herrmann 2014-03-27 20:08:23 UTC
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.