Bug 69764 - [bug] rapidly switching VTs between Weston and a Terminal can lock Weston
Summary: [bug] rapidly switching VTs between Weston and a Terminal can lock Weston
Status: VERIFIED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-24 17:30 UTC by Brian Lovin
Modified: 2013-10-25 00:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Lovin 2013-09-24 17:30:21 UTC
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.
Comment 1 Brian Lovin 2013-09-24 22:19:05 UTC
The hardware this bug was recreated on:
NDIS166 sandybridge
Comment 2 U. Artie Eoff 2013-09-24 22:34:22 UTC
(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.
Comment 3 U. Artie Eoff 2013-10-07 16:47:35 UTC
Also, I observed a:

"queueing pageflip failed: Permission denied"

prior to the lockup
Comment 4 Rafal Mielniczuk 2013-10-17 19:28:54 UTC
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
Comment 5 Kristian Høgsberg 2013-10-24 18:33:22 UTC
(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.
Comment 6 Kristian Høgsberg 2013-10-24 18:34:31 UTC
(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.