NetBSD Problem Report #41082

From yamt@mwd.biglobe.ne.jp  Fri Mar 27 06:31:09 2009
Return-Path: <yamt@mwd.biglobe.ne.jp>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id AB98063B8BA
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 27 Mar 2009 06:31:09 +0000 (UTC)
Message-Id: <20090327051134.BF68997EED@kaeru.lan>
Date: Fri, 27 Mar 2009 14:11:34 +0900 (JST)
From: yamt@mwd.biglobe.ne.jp
Reply-To: yamt@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: destroying a locked vlockmgr lock on shutdown
X-Send-Pr-Version: 3.95

>Number:         41082
>Category:       kern
>Synopsis:       destroying a locked vlockmgr lock on shutdown
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 27 06:35:00 +0000 2009
>Closed-Date:    Sun May 01 05:29:06 +0000 2016
>Last-Modified:  Sun May 01 05:29:06 +0000 2016
>Originator:     YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
>Release:        NetBSD 5.99.8
>Organization:

>Environment:


System: NetBSD kaeru 5.99.8
Architecture: i386
Machine: i386
>Description:
	see below.  it happened on "shutdown -r now".
	the system's uptime was only a few minutes.
	64 == offsetof(vnode, v_op).


NetBSD/i386 (nfskuro) (console)

login: Mar 27 10:01:50 nfskuro shutdown: reboot by takashi:
Reader / writer lock error: rw_destroy: assertion failed: (rw->rw_owner & ~RW_DEBUG) == 0

lock address : 0x00000000d77d1718 type     :     sleep/adaptive
initialized  : 0x00000000c0473f20
shared holds :                  0 exclusive:                  1
shares wanted:                  0 exclusive:                  0
current cpu  :                  2 last held:                  2
current lwp  : 0x00000000d6911020 last held: 0x00000000d6911020
last locked  : 0x00000000c0471796 unlocked : 0x00000000c0471768
owner/count  : 0x00000000d6911020 flags    : 0x000000000000000c

Turnstile chain at 0xc05b3a78.
=> No active turnstile for this lock.

panic: LOCKDEBUG
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c01566c4 cs 8 eflags 246 cr2 bb600240 ilevel 8
Stopped in pid 109.1 (syslogd) at       netbsd:breakpoint+0x4:  popl    %ebp
db{2}> p/a 0x00000000c0471796
netbsd:vlockmgr+0x126
db{2}> ps/l
PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
427      1 3   1        84           d767aa60             reboot nanoslp
109  >   1 7   2         4           d6911020            syslogd
1        1 3   3         4           d6902360               init vnode
0       66 3   2       204           d69117a0        vmem_rehash vmem_rehash
0       65 2   2       204           d6911a20           aiodoned
0       64 3   1       204           d6911ca0            ioflush syncer
0       63 3   2       204           d690d000           pgdaemon pgdaemon
0       62 3   2       204           d690d280              nfsio nfsiod
0       61 3   2       204           d690d500              nfsio nfsiod
0       60 3   1       204           d690d780              nfsio nfsiod
0       59 3   2       204           d690da00              nfsio nfsiod
0       58 3   3       204           d690dc80            pfpurge pftm
0       57 3   2       204           d69015c0          cryptoret crypto_wait
0       55 3   2       204           d6901ac0               usb4 usbevt
0       54 3   2       204           d6902d60               usb2 usbevt
0       53 3   2       204           d69020e0               usb7 usbevt
0       52 3   2       204           d6901340              unpgc unpgc
0       51 3   2       204           d6901d40               usb5 usbevt
0       50 3   3       204           d6901840               usb1 usbevt
0       49 3   3       204           d69000a0               usb3 usbevt
0       48 3   3       204           d69010c0               usb0 usbevt
db{2}> t
breakpoint(c054c7ca,d71fdaf8,d65b80c0,c03c91da,c054c7ca,1,0,0,d71fdaf8,8) at net
bsd:breakpoint+0x4
panic(c054c7cc,c052fa57,c04e5969,c052f6fc,c04e5969,126a9aa,0,d77d1718,d77d168c,d
77d1678) at netbsd:panic+0x1c9
lockdebug_abort1(c052f6fc,1,c04e5969,c052f6fc,8,c03b06ae,d71fdb4c,c026a9f1,1c,d7
7d1678) at netbsd:lockdebug_abort1+0xbb
rw_abort(1c,d77d1678,d71fdb7c,c0473dbe,d77d1718,18,d71fdb7c,c0474279,d7157004,c0
474be3) at netbsd:rw_abort+0x2a
rw_destroy(d77d1718,18,d71fdb7c,c0474279,d7157004,c0474be3,d71706e0,1,d77d168c,1
) at netbsd:rw_destroy+0x41
vnfree(d77d1678,d6911020,0,0,d77d1678,7,d71fdbcc,c048babf,1,0) at netbsd:vnfree+
0x8e
vrelel(d77d1678,0,d71fdbec,c0475475,d77d1678,0,d77d1678,0,d77d1678,7) at netbsd:
vrelel+0x346
vrele(d77d1678,a,d440af00,d691ae9c,0,d691ae80,d71fdc2c,c047d842,d77d1678,a) at n
etbsd:vrele+0x6e
vn_close(d77d1678,a,d440af00,d691ae9c,d691ae9c,d691ae80,d71fdc7c,c024da4d,d691ae
80,d750ecc0) at netbsd:vn_close+0x58
vn_closefile(d691ae80,d750ecc0,d71fdc6c,0,c024dc06,d6911020,0,d750ecc0,0,7) at n
etbsd:vn_closefile+0x22
closef(d691ae80,7,d71fdd00,c03ddc62,d71fdcb0,bfbfeca0,10,c024df50,d6919e48,d691a
e80) at netbsd:closef+0x5d
fd_close(7,d71fdd00,d71fdd28,d71fdd40,c034f570,d690b960,2,7,bb82d070,bfbfecc8) a
t netbsd:fd_close+0x121
syscall(d71fdd48,bb8100b3,ab,bfbf001f,bba0001f,bb82d070,bb842060,bfbfecc8,bb83b8
00,0) at netbsd:syscall+0xc8
db{2}> sh vn d77d1678
OBJECT 0xd77d1678: locked=0, pgops=0xc050afc0, npages=0, refs=0

VNODE flags 0x280004<ISTTY,CLEAN,INACTREDO>
mp 0x0 numoutput 0 size 0x0 writesize 0x0
data 0x0 writecount 0 holdcnt 0
tag UNKNOWN(0) type VCHR(4) mount 0x0 typedata 0x0
v_lock 0xd77d1718 v_vnlock 0xd77d1718
db{2}> x d77d1678+64
0xd77d16dc:     d6219d0c
db{2}> x/x dead_vnodeop_p
netbsd:dead_vnodeop_p:  d6219d0c
db{2}>
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 05 Sep 2015 20:30:40 +0000
State-Changed-Why:
Have you seen this recently? I would have expected the ongoing vnode
lifecycle cleanup to have fixed it.


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 11 Sep 2015 02:32:42 +0000
State-Changed-Why:
update submitter address...


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 11 Sep 2015 02:33:03 +0000
State-Changed-Why:
and try again:

Have you seen this recently? I would have expected the ongoing vnode
lifecycle cleanup to have fixed it.


State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 01 May 2016 05:29:06 +0000
State-Changed-Why:
feedback timeout, let's assume fixed unless/until it reappears.


>Unformatted:

Home	PR Database Search