Software Stack: Fedora 19 wayland (HEAD) 1.2.91-0-g4125367 drm (HEAD) libdrm-2.4.46-0-gc6d73cf mesa (9.2) heads/9.2-0-g2cda3f0 libva (HEAD) libva-1.2.1-0-g88ed1eb intel-driver (HEAD) 1.2.0-0-g6898ab7 weston (HEAD) 1.2.91-0-g7799385 Switching between a VT and Weston can cause Weston to lock. This bug is a little hard to recreate. Start Weston with the display mode set to 'current' (this speeds up the time to switch between a VT and Weston). Rapidly switch between a VT and Weston by holding <alt>+<ctrl> and pressing the correct F keys. After switching to Weston, try pressing the same F-key again (as if switching to Weston), then rapidly pressing the second F-key (For Example, press: F2,F1,F1,F1,F2). You should notice Weston will stop responding to input, including switching to another VT.
The hardware this bug was recreated on: NDIS166 sandybridge
(In reply to comment #1) > The hardware this bug was recreated on: > NDIS166 sandybridge FWIW, I was not able to duplicate this on my IvyBridge (i5-3317U). However, I could reproduce it easily on my NDIS166 Sandybridge. Both on 3.9.5-301.fc19.x86_64 kernel.
Also, I observed a: "queueing pageflip failed: Permission denied" prior to the lockup
I am not 100% sure if this is related, but in drm backend, after switching vt a couple of times, open fds get accumulated by the weston-launch process. When their count hits system limits, it then hangs the weston session. Errors show: Error opening device /dev/input/event6: Too many open files Open fds after some vt switches: $ sudo ls -l /proc/14112/fd lrwx------ 1 root root 64 10-17 21:19 0 -> /dev/tty1 lrwx------ 1 root root 64 10-17 21:19 1 -> /dev/tty1 lrwx------ 1 root root 64 10-17 21:19 10 -> /dev/input/event5 lrwx------ 1 root root 64 10-17 21:19 11 -> /dev/input/event13 lrwx------ 1 root root 64 10-17 21:19 12 -> /dev/input/event7 lrwx------ 1 root root 64 10-17 21:19 13 -> /dev/input/event10 lrwx------ 1 root root 64 10-17 21:19 14 -> /dev/input/event8 lrwx------ 1 root root 64 10-17 21:19 15 -> /dev/input/event9 lrwx------ 1 root root 64 10-17 21:19 16 -> /dev/input/event2 lrwx------ 1 root root 64 10-17 21:19 17 -> /dev/input/event12 lrwx------ 1 root root 64 10-17 21:19 18 -> /dev/input/event6 lrwx------ 1 root root 64 10-17 21:19 19 -> /dev/input/event11 lrwx------ 1 root root 64 10-17 21:19 2 -> /dev/tty1 lrwx------ 1 root root 64 10-17 21:19 20 -> /dev/input/event1 lrwx------ 1 root root 64 10-17 21:19 21 -> /dev/input/event4 lrwx------ 1 root root 64 10-17 21:19 22 -> /dev/input/event3 lrwx------ 1 root root 64 10-17 21:19 23 -> /dev/input/event0 lrwx------ 1 root root 64 10-17 21:19 24 -> /dev/input/event5 lrwx------ 1 root root 64 10-17 21:19 25 -> /dev/input/event13 lrwx------ 1 root root 64 10-17 21:19 26 -> /dev/input/event7 lrwx------ 1 root root 64 10-17 21:19 27 -> /dev/input/event10 lrwx------ 1 root root 64 10-17 21:19 28 -> /dev/input/event8 lrwx------ 1 root root 64 10-17 21:19 29 -> /dev/input/event9 lrwx------ 1 root root 64 10-17 21:19 3 -> socket:[81634] lrwx------ 1 root root 64 10-17 21:19 30 -> /dev/input/event2 lrwx------ 1 root root 64 10-17 21:19 31 -> /dev/input/event12 lrwx------ 1 root root 64 10-17 21:19 32 -> /dev/input/event6 lrwx------ 1 root root 64 10-17 21:19 33 -> /dev/input/event11 lrwx------ 1 root root 64 10-17 21:19 4 -> /dev/dri/card0 lrwx------ 1 root root 64 10-17 21:19 5 -> anon_inode:[signalfd] lrwx------ 1 root root 64 10-17 21:19 6 -> /dev/input/event1 lrwx------ 1 root root 64 10-17 21:19 7 -> /dev/input/event4 lrwx------ 1 root root 64 10-17 21:19 8 -> /dev/input/event3 lrwx------ 1 root root 64 10-17 21:19 9 -> /dev/input/event0
(In reply to comment #3) > Also, I observed a: > > "queueing pageflip failed: Permission denied" > > prior to the lockup This should be fixed by: commit 3c688c5e33873100abab56735eb44f53eb3a6d6b Author: David Herrmann <dh.herrmann@gmail.com> Date: Tue Oct 22 17:11:25 2013 +0200 compositor-drm: finish frame if initial page-flip fails If the initial page-flip fails, immediately finish the frame to avoid being stuck in the given frame. We already do this if we have no fbo available. Now we do the same if the page-flip fails. What happened (both for weston-launch but it's also the case for logind) is that we used to be able to drop kms priviledges at the right time in the repaint cycle and thus pageflip would never just fail. Now, weston-launch or logind will drop kms master for us without synchronizing with weston, so we have to be able to handle kms operations failing at any time and recover gracefully. That's what Davids patch does.
(In reply to comment #4) > I am not 100% sure if this is related, but in drm backend, after switching > vt a couple of times, open fds get accumulated by the weston-launch process. > When their count hits system limits, it then hangs the weston session. > Errors show: > > Error opening device /dev/input/event6: Too many open files > > Open fds after some vt switches: > $ sudo ls -l /proc/14112/fd > lrwx------ 1 root root 64 10-17 21:19 0 -> /dev/tty1 > lrwx------ 1 root root 64 10-17 21:19 1 -> /dev/tty1 > lrwx------ 1 root root 64 10-17 21:19 10 -> /dev/input/event5 > lrwx------ 1 root root 64 10-17 21:19 11 -> /dev/input/event13 > lrwx------ 1 root root 64 10-17 21:19 12 -> /dev/input/event7 > lrwx------ 1 root root 64 10-17 21:19 13 -> /dev/input/event10 > lrwx------ 1 root root 64 10-17 21:19 14 -> /dev/input/event8 > lrwx------ 1 root root 64 10-17 21:19 15 -> /dev/input/event9 > lrwx------ 1 root root 64 10-17 21:19 16 -> /dev/input/event2 > lrwx------ 1 root root 64 10-17 21:19 17 -> /dev/input/event12 > lrwx------ 1 root root 64 10-17 21:19 18 -> /dev/input/event6 > lrwx------ 1 root root 64 10-17 21:19 19 -> /dev/input/event11 > lrwx------ 1 root root 64 10-17 21:19 2 -> /dev/tty1 > lrwx------ 1 root root 64 10-17 21:19 20 -> /dev/input/event1 > lrwx------ 1 root root 64 10-17 21:19 21 -> /dev/input/event4 > lrwx------ 1 root root 64 10-17 21:19 22 -> /dev/input/event3 > lrwx------ 1 root root 64 10-17 21:19 23 -> /dev/input/event0 > lrwx------ 1 root root 64 10-17 21:19 24 -> /dev/input/event5 > lrwx------ 1 root root 64 10-17 21:19 25 -> /dev/input/event13 > lrwx------ 1 root root 64 10-17 21:19 26 -> /dev/input/event7 > lrwx------ 1 root root 64 10-17 21:19 27 -> /dev/input/event10 > lrwx------ 1 root root 64 10-17 21:19 28 -> /dev/input/event8 > lrwx------ 1 root root 64 10-17 21:19 29 -> /dev/input/event9 > lrwx------ 1 root root 64 10-17 21:19 3 -> socket:[81634] > lrwx------ 1 root root 64 10-17 21:19 30 -> /dev/input/event2 > lrwx------ 1 root root 64 10-17 21:19 31 -> /dev/input/event12 > lrwx------ 1 root root 64 10-17 21:19 32 -> /dev/input/event6 > lrwx------ 1 root root 64 10-17 21:19 33 -> /dev/input/event11 > lrwx------ 1 root root 64 10-17 21:19 4 -> /dev/dri/card0 > lrwx------ 1 root root 64 10-17 21:19 5 -> anon_inode:[signalfd] > lrwx------ 1 root root 64 10-17 21:19 6 -> /dev/input/event1 > lrwx------ 1 root root 64 10-17 21:19 7 -> /dev/input/event4 > lrwx------ 1 root root 64 10-17 21:19 8 -> /dev/input/event3 > lrwx------ 1 root root 64 10-17 21:19 9 -> /dev/input/event0 That's a different issue, but something that we need to fix. Can you open a new bug with this info? Thanks.
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.