Bug #3200

master: weston screen freezes

Added by peeter 3 months ago. Updated about 7 hours ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


It has now happened at least four times in a row. After a few days of uptime, weston freezes. I can still ssh into the machine, everything else seems fine except the graphics screen is frozen. ps axlRH shows that weston is in state 'drmev'.

1001 1262 1 1261 25 199 0 266664 193568 drmev D0+ v1 7:36.42 /usr/local/bin/weston --use-pixman

This is the 'stuct event_lock' in 'struct drm_device', which is used among other things in the context of ioctls. kgdb shows this backtrace for weston:

(kgdb) thread 1096
[Switching to thread 1096 (pid 1262/1, weston)]
#0 0xffffffff80665e76 in lwkt_switch () at /usr/src/sys/kern/lwkt_thread.c:810
810 lwkt_switch_return(td->td_switch(ntd));
(kgdb) bt
#0 0xffffffff80665e76 in lwkt_switch () at /usr/src/sys/kern/lwkt_thread.c:810
#1 0xffffffff8067300e in tsleep (ident=ident@entry=0xfffff8037b927c70, flags=flags@entry=1024, wmesg=<optimized out>, timo=timo@entry=0)
at /usr/src/sys/kern/kern_synch.c:707
#2 0xffffffff8064040d in lockmgr_exclusive (lkp=lkp@entry=0xfffff8037b927c70, flags=flags@entry=2) at /usr/src/sys/kern/kern_lock.c:381
#3 0xffffffff83087a66 in lockmgr (flags=2, lkp=0xfffff8037b927c70) at @/sys/lock.h:271
#4 spin_lock_irq (lock=0xfffff8037b927c70) at /usr/src/sys/dev/drm/i915/../../../dev/drm/include/linux/spinlock.h:55
#5 intel_crtc_has_pending_flip (crtc=<optimized out>) at /usr/src/sys/dev/drm/i915/intel_display.c:3223
#6 intel_crtc_wait_for_pending_flips (crtc=<optimized out>) at /usr/src/sys/dev/drm/i915/intel_display.c:3841
#7 intel_atomic_prepare_commit (nonblock=<optimized out>, state=0xfffff8042ca0f340, dev=<optimized out>)
at /usr/src/sys/dev/drm/i915/intel_display.c:13480
#8 intel_atomic_commit (dev=<optimized out>, state=0xfffff8042ca0f340, nonblock=<optimized out>)
at /usr/src/sys/dev/drm/i915/intel_display.c:13614
#9 0xffffffff83d7bf6c in drm_atomic_helper_set_config (set=0xfffff80390f8d678) at /usr/src/sys/dev/drm/drm/../drm_atomic_helper.c:1878
#10 0xffffffff83d54842 in drm_mode_set_config_internal (set=set@entry=0xfffff80390f8d678) at /usr/src/sys/dev/drm/drm/../drm_crtc.c:2687
#11 0xffffffff83d54f60 in drm_mode_setcrtc (dev=0xfffff8037b927900, data=0xfffff80390f8d868, file_priv=<optimized out>)
at /usr/src/sys/dev/drm/drm/../drm_crtc.c:2919
#12 0xffffffff83d704f1 in drm_ioctl (ap=<optimized out>) at /usr/src/sys/dev/drm/drm/../drm_ioctl.c:705
#13 0xffffffff80627885 in dev_dioctl (dev=dev@entry=0xfffff801581b1c80, cmd=cmd@entry=3228066978,
data=data@entry=0xfffff80390f8d868 "\360\003\270", fflag=<optimized out>, cred=cred@entry=0xfffff8007370f190,
msg=msg@entry=0xfffff80390f8d960, fp=0xfffff8037acb3180) at /usr/src/sys/kern/kern_device.c:244
#14 0xffffffff808f78e5 in devfs_fo_ioctl (fp=0xfffff8037acb3180, com=3228066978, data=0xfffff80390f8d868 "\360\003\270",
ucred=0xfffff8007370f190, msg=0xfffff80390f8d960) at /usr/src/sys/vfs/devfs/devfs_vnops.c:1545
#15 0xffffffff80697f6a in fo_ioctl (msg=<optimized out>, cred=<optimized out>, data=<optimized out>, com=<optimized out>, fp=0xfffff8037acb3180)
at /usr/src/sys/sys/file2.h:84
#16 mapped_ioctl (fd=<optimized out>, com=<optimized out>, uspc_data=<optimized out>, map=0x0, msg=<optimized out>)
at /usr/src/sys/kern/sys_generic.c:717
#17 0xffffffff80b96400 in syscall2 (frame=0xfffff80390f8d9f8) at /usr/src/sys/platform/pc64/x86_64/trap.c:1308
#18 0xffffffff80b7159d in ?? () at /usr/src/sys/platform/pc64/x86_64/exception.S:450
#19 0x0000000000000009 in ?? ()
#20 0x00000000c06864a2 in ?? ()
#21 0x00007fffffdfc8a0 in ?? ()
#22 0x0000000000000000 in ?? ()

Not sure this is helpful but that's all I've got for now.

I attach the output of 'ps axlRH', maybe there's something else I should look out for.




drmev-psalRH.out (159 KB) drmev-psalRH.out peeter, 08/05/2019 11:24 AM



Updated by peeter 3 months ago

OK this bug has now become my daily companion. Can't find the deadlock.


Updated by peeter 3 months ago

The machine is intel i7 skylake (i7-6700).


Updated by peeter about 7 hours ago

I seem to have forgotten to specify how to reproduce the situation:

Create a minimalistic ~/.config/weston.ini


Then start weston with

% weston-launch -- --use-pixman >& log/weston.0.log

Click on the terminal icon in the left top corner to start a wayland terminal. Then start chrome manually in that window

% chrome &

Go to and start playing videos. No further interaction needed, sit back and wait until freeze occurs.

Also available in: Atom PDF