>Number: 55237
>Category: kern
>Synopsis: Panic: vrelel: bad ref count (9.99.54)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue May 05 21:35:01 +0000 2020
>Originator: Andrew Doran
>Release: NetBSD 9.99.54
>Organization:
The NetBSD Project
>Environment:
amd64
>Description:
Date: Mon, 04 May 2020 15:54:57 +0200
From: Leonardo Taccari <leot%NetBSD.org@localhost>
To: Yorick Hardy <yorickhardy%gmail.com@localhost>, Andrew Doran <ad%netbsd.org@localhost>
cc: current-users%NetBSD.org@localhost
Subject: Re: Panic: vrelel: bad ref count (9.99.54)
Hello Yorick and Andrew,
Yorick Hardy writes:
> > > > [...]
> > > >
> > > > Crash version 9.99.55, image version 9.99.55.
> > > > crash: _kvm_kvatop(0)
> > > > Kernel compiled without options LOCKDEBUG.
> > > > System panicked: vrelel: bad ref count
> > > > Backtrace from time of crash is available.
> > > > crash> bt
> > > > _KERNEL_OPT_NAGR() at 0
> > > > ?() at 7f7ff7ecf000
> > > > sys_reboot() at sys_reboot
> > > > vpanic() at vpanic+0x181
> > > > vtryrele() at vtryrele
> > > > vcache_dealloc() at vcache_dealloc
> > > > uvm_unmap_detach() at uvm_unmap_detach+0x76
> > > > uvm_unmap1() at uvm_unmap1+0x4e
> > > > uvm_mremap() at uvm_mremap+0x36b
> > > > sys_mremap() at sys_mremap+0x68
> > > > syscall() at syscall+0x227
> > > > --- syscall (number 411) ---
> > > > 797459842e9a:
> > > > crash>
> > >
> > > The same just happened on 9.99.56 while fetching (POP) mail using mail/fdm.
> >
> > Could you file a PR please? If this panics again could you please run the
> > "dmesg" command in crash and find out what it printed about the vnode? That
> > would be very useful.
> >
> > Thanks,
> > Andrew
>
> I will do so (... perhaps only this weekend).
> [...]
I was able to reproduce it too with a yesterday evening NetBSD/amd64
-current when using mail/fdm and I will try to prepare a minimal
reproducer using mail/fdm and file a PR if noone beat me.
In the meantime here the information from dmesg:
[ 6107.6380323] vnode 0xffffa95219747d40 flags 0x418<MAPPED,MPSAFE,WRMAP>
[ 6107.6380323] tag VT_TMPFS(25) type VREG(1) mount 0xffffa951f6d89000 typedata 0xffffa95255e32c90
[ 6107.6380323] usecount 1 writecount 1 holdcount 0
[ 6107.6380323] size 18000 writesize 18000 numoutput 0
[ 6107.6380323] data 0xffffa952583304a0 lock 0xffffa95219747f00
[ 6107.6380323] state LOADED key(0xffffa951f6d89000 8) a0 04 33 58 52 a9 ff ff
[ 6107.6380323] lrulisthd 0xffffffff816b5ed0
[ 6107.6380323] tag VT_TMPFS, tmpfs_node 0xffffa952583304a0, flags 0x0, links 1
[ 6107.6380323] mode 0600, owner 1000, group 0, size 98304
[ 6107.6380323] panic: vrelel: bad ref count
[ 6107.6380323] cpu0: Begin traceback...
[ 6107.6380323] vpanic() at netbsd:vpanic+0x178
[ 6107.6480364] vnpanic() at netbsd:vnpanic+0x49
[ 6107.6480364] vrelel() at netbsd:vrelel+0x5b6
[ 6107.6480364] uvm_unmap_detach() at netbsd:uvm_unmap_detach+0x8e
[ 6107.6480364] sys_munmap() at netbsd:sys_munmap+0x85
[ 6107.6480364] syscall() at netbsd:syscall+0x2a0
[ 6107.6480364] --- syscall (number 73) ---
[ 6107.6480364] 7c1e5d18414a:
[ 6107.6480364] cpu0: End traceback...
[ 6107.6480364] fatal breakpoint trap in supervisor mode
[ 6107.6480364] trap type 1 code 0 rip 0xffffffff802219fd cs 0x8 rflags 0x202 cr2 0x7f7ff7ee5000 ilevel 0 rsp 0xffffc100c227ae20
[ 6107.6480364] curlwp 0xffffa9521e1b1600 pid 20756.20756 lowest kstack 0xffffc100c22772c0
[ 6107.6480364] dumping to dev 0,1 (offset=276847, size=2062664):
[ 6107.6480364] dump
If any possible further information is needed do not hesitate to
contact me!
Thanks!
>How-To-Repeat:
Suggestion above.
>Fix:
Yes please.