From owner-freebsd-fs@freebsd.org Thu Jan 28 12:36:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B52EAA71800 for ; Thu, 28 Jan 2016 12:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B1BC1756 for ; Thu, 28 Jan 2016 12:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SCaX9I035808 for ; Thu, 28 Jan 2016 12:36:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 12:36:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 12:36:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #4 from Daniel Ylitalo --- Okay! Got a proc stuck again, however, I'm having trouble understanding "fi= nd the vnode address which caused the hang", how do I know what caused the han= g? Heres all the output I've gatherd so far: procstat -kk -a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 94614 100627 python2.7 - mi_switch+0x179 sleepq_switch+0x152 sleepq_wait+0x43 _sleep+0x366 vnode_create_vobject+0xe9 ufs_lookup_ino+0xa0 VOP_CACHEDLOOKUP_APV+0x10f vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0x10f lookup+0x5c2 namei+0x504 kern_statat_vnhook+0xae sys_lstat+0x30 amd64_syscall+0x278 Xfast_syscall+0xfb =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [root@hub-se /usr/obj/usr/src/sys/GENERIC]# kgdb kernel.debug /dev/mem GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Reading symbols from /boot/kernel/aio.ko.symbols...done. Loaded symbols for /boot/kernel/aio.ko.symbols Reading symbols from /boot/kernel/accf_data.ko.symbols...done. Loaded symbols for /boot/kernel/accf_data.ko.symbols Reading symbols from /boot/kernel/accf_http.ko.symbols...done. Loaded symbols for /boot/kernel/accf_http.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/nullfs.ko.symbols...done. Loaded symbols for /boot/kernel/nullfs.ko.symbols #0 sched_switch (td=3D0xffffffff81850720, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 1945 cpuid =3D PCPU_GET(cpuid); (kgbd) info threads 505 Thread 100627 (PID=3D94614: python2.7) sched_switch (td=3D0xfffff80379b5e940, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 (kgdb) thread 505 [Switching to thread 505 (Thread 100627)]#0 sched_switch (td=3D0xfffff80379b5e940, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 1945 cpuid =3D PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=3D0xfffff80379b5e940, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 #1 0xffffffff8094e149 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/sys/kern/kern_synch.c:491 #2 0xffffffff8098bb02 in sleepq_switch (wchan=3D, pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:538 #3 0xffffffff8098b963 in sleepq_wait (wchan=3D0xfffff808cdd41e00, pri=3D84= ) at /usr/src/sys/kern/subr_sleepqueue.c:617 #4 0xffffffff8094da56 in _sleep (ident=3D, lock=3D, priority=3D, wmesg=3D, sbt=3D, pr=3D) at /usr/src/sys/kern/kern_synch.c:255 #5 0xffffffff80be8759 in vnode_create_vobject (vp=3D0xfffff8036ee569c0, isize=3D512, td=3D0xfffff80379b5e940) at /usr/src/sys/vm/vnode_pager.c:120 #6 0xffffffff80bb1010 in ufs_lookup_ino (vdp=3D0xfffff8036ee569c0, vpp=3D0xfffffe0a5bdfd9a8, cnp=3D0xfffffe0a5bdfd9d0, dd_ino=3D0x0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:259 #7 0xffffffff80e791ef in VOP_CACHEDLOOKUP_APV (vop=3D, a=3D) at vnode_if.c:197 #8 0xffffffff809dba26 in vfs_cache_lookup (ap=3D) at vnode_if.h:80 #9 0xffffffff80e7902f in VOP_LOOKUP_APV (vop=3D, a=3D= ) at vnode_if.c:129 #10 0xffffffff809e40c2 in lookup (ndp=3D0xfffffe0a5bdfd948) at vnode_if.h:54 #11 0xffffffff809e3764 in namei (ndp=3D0xfffffe0a5bdfd948) at /usr/src/sys/kern/vfs_lookup.c:302 #12 0xffffffff809f911e in kern_statat_vnhook (td=3D0xfffff80379b5e940, flag=3D, fd=3D-100, path=3D0x8067103d4 , pathseg=3DUIO_USERSPACE, sbp=3D0xfffffe0a5bdfda6= 0, hook=3D0) at /usr/src/sys/kern/vfs_syscalls.c:2298 #13 0xffffffff809f92b0 in sys_lstat (td=3D0x0, uap=3D0xfffffe0a5bdfdb80) at /usr/src/sys/kern/vfs_syscalls.c:2278 #14 0xffffffff80d51b38 in amd64_syscall (td=3D0xfffff80379b5e940, traced=3D= 0) at subr_syscall.c:134 #15 0xffffffff80d359ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #16 0x000000080157f8aa in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I'm letting the server stay stuck until I know how to get the info you need= out of it :) --=20 You are receiving this mail because: You are the assignee for the bug.=