kern/129956: Threadened process stuck in "vmopar" state, other in "ufs" later.

pluknet pluknet at gmail.com
Mon Dec 29 17:30:03 UTC 2008


The following reply was made to PR threads/129956; it has been noted by GNATS.

From: pluknet <pluknet at gmail.com>
To: bug-followup at freebsd.org
Cc:  
Subject: Re: kern/129956: Threadened process stuck in "vmopar" state, other in "ufs" later.
Date: Mon, 29 Dec 2008 19:54:32 +0300

 HTH,
 
 db> show lockedvnods
 Locked vnodes
 
 0xc86d6aa0: tag syncer, type VNON
     usecount 1, writecount 0, refcount 2 mountedhere 0
     flags ()
      lock type syncer: EXCL (count 1) by thread 0xc8341680 (pid 50)
 
 0xc9f62880: tag ufs, type VREG
     usecount 0, writecount 0, refcount 3 mountedhere 0
     flags (VI_DOOMED)
     v_object 0xca794840 ref 0 pages 592
      lock type ufs: EXCL (count 1) by thread 0xc9813340 (pid 13253)
 with 1 pending
         ino 68191367, on dev aacdu0s1g
 db> ps
 13262 13001 13262  1000  S+      ufs      0xc9f628d8 sync
 13253     1 13251  1000  SE      vmopar   0xc3e83d58 httpd
 ..
    50     0     0     0  SL      ufs      0xc9f628d8 [syncer]
 ..
 db> bt 13262
 Tracing pid 13262 tid 100104 td 0xc88934e0
 sched_switch(c88934e0,0,1) at sched_switch+0x15b
 mi_switch(1,0) at mi_switch+0x270
 sleepq_switch(c9f628d8,c0a80360,0,c098ab1f,21f,...) at sleepq_switch+0xc1
 sleepq_wait(c9f628d8,0,c9f628fc,b7,c0992135,...) at sleepq_wait+0x46
 msleep(c9f628d8,c0a7fa74,50,c098f56b,0,...) at msleep+0x27d
 acquire(eecbfb7c,40,60000,c88934e0,0,...) at acquire+0x76
 lockmgr(c9f628d8,2002,c9f628fc,c88934e0) at lockmgr+0x42a
 ffs_lock(eecbfbd4) at ffs_lock+0x6e
 VOP_LOCK_APV(c0a4a7e0,eecbfbd4) at VOP_LOCK_APV+0x87
 vn_lock(c9f62880,2002,c88934e0,c9f62880) at vn_lock+0xa8
 vget(c9f62880,2002,c88934e0) at vget+0xba
 qsync(c85dd530,c85dd574,21f7,1,0,...) at qsync+0x11a
 ffs_sync(c85dd530,2,c88934e0,c85dd530,2,...) at ffs_sync+0x2b0
 sync(c88934e0,eecbfd04) at sync+0xe8
 syscall(3b,3b,3b,2804e9c8,bfbfedd8,...) at syscall+0x22f
 Xint0x80_syscall() at Xint0x80_syscall+0x1f
 --- syscall (36, FreeBSD ELF32, sync), eip = 0x280bb617, esp =
 0xbfbfed6c, ebp = 0xbfbfed88 ---
 
 db> bt 50
 Tracing pid 50 tid 100038 td 0xc8341680
 sched_switch(c8341680,0,1) at sched_switch+0x15b
 mi_switch(1,0) at mi_switch+0x270
 sleepq_switch(c9f628d8,c0a80360,0,c098ab1f,21f,...) at sleepq_switch+0xc1
 sleepq_wait(c9f628d8,0,c9f628fc,b7,c0991825,...) at sleepq_wait+0x46
 msleep(c9f628d8,c0a7fa74,50,c098f56b,0,...) at msleep+0x27d
 acquire(e8957b24,40,60000,c8341680,0,...) at acquire+0x76
 lockmgr(c9f628d8,2002,c9f628fc,c8341680) at lockmgr+0x42a
 ffs_lock(e8957b7c) at ffs_lock+0x6e
 VOP_LOCK_APV(c0a4a7e0,e8957b7c) at VOP_LOCK_APV+0x87
 vn_lock(c9f62880,2002,c8341680,c9f62880) at vn_lock+0xa8
 vget(c9f62880,2002,c8341680) at vget+0xba
 qsync(c85dd530,c85dd574,21f6,1,0,...) at qsync+0x11a
 ffs_sync(c85dd530,3,c8341680,c85dd530,2,...) at ffs_sync+0x2b0
 sync_fsync(e8957cbc) at sync_fsync+0x15a
 VOP_FSYNC_APV(c0a178a0,e8957cbc) at VOP_FSYNC_APV+0x7e
 sync_vnode(c86d6b60,c8341680) at sync_vnode+0x100
 sched_sync(0,e8957d38,0,c072a858,0,...) at sched_sync+0x1ed
 fork_exit(c072a858,0,e8957d38) at fork_exit+0xa0
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0x1, eip = 0, esp = 0xe8957d6c, ebp = 0 ---


More information about the freebsd-threads mailing list