Issue #3200 has been updated by dillon.

So far ftigeot has not had any luck reproducing it, but there's almost enough 
information in the bug report to track the issue down.  What we have in your 
original backtrace is that it's stuck trying to acquire a lock, which means 
that some other thread likely holds the lock.  We have to find that other 
thread and get a backtrace of *it* as well.

One way to do this is to get into kgdb and get the backtrace you have above, 
then push into the frame where the struct lock is available (such as frame 2 in 
the above backtrace), then 'print *lkp'.

Once you have the lock contents, if the lk_lockholder field is not NULL you 
should be able to track down the process/thread that is holding the lock:

print lkp->lk_lockholder
print lkp->lk_lockholder->td_comm
print lkp->lk_lockholder->td_proc->p_pid

If its a user process it will have a td_proc .. but hopefully from that you can 
use the 'info thread' output from kgdb to find the thread, then switch to it 
and get a backtrace of THAT thread too.


Bug #3200: master: weston screen freezes

* Author: peeter
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
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 

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 
#4  spin_lock_irq (lock=0xfffff8037b927c70) at 
#5  intel_crtc_has_pending_flip (crtc=<optimized out>) at 
#6  intel_crtc_wait_for_pending_flips (crtc=<optimized out>) at 
#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 
#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 
#13 0xffffffff80627885 in dev_dioctl (dev=dev@entry=0xfffff801581b1c80, 
    data=data@entry=0xfffff80390f8d868 "\360\003\270", fflag=<optimized out>, 
    msg=msg@entry=0xfffff80390f8d960, fp=0xfffff8037acb3180) at 
#14 0xffffffff808f78e5 in devfs_fo_ioctl (fp=0xfffff8037acb3180, 
com=3228066978, data=0xfffff80390f8d868 "\360\003\270", 
    ucred=0xfffff8007370f190, msg=0xfffff80390f8d960) at 
#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 
#18 0xffffffff80b7159d in ?? () at 
#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)

You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here:

Reply via email to