Re: consistent crashes on NetBSD 7.99.24 amd64 built 19th Dec 15

[Paul Goyette <paul%whooppee.com@localhost>]

I wonder if this is related to something I have recently seen? ...

On at least two occassions I have had a 'rm -rf <dir>' fail with the 
error "directory not empty".  An 'ls -a' doesn't display anything, and 
yet the directory cannot be removed.

On both occassions, I was able to 'mv <dir> <mount-point>/' (moved it to 
the top of its current file-system mount-point).  The first time, it was 
still unremovable, so I unmounted the file-system at <mount-point> and 
did a 'fsck -f'.  The machine panic'd, but unfortunately I did not 
record any details.

The second time, after 'mv' I used hexdump on the directory, and it 
showed a couple of entries.  I was able to manually remove them, and 
then I was able to remove the directory (since it was now empty).

I don't remember what higher-level task I was doing the first time, but 
the second time I was in the middle of a 'cvs update'.

Hmmm....


On Thu, 31 Dec 2015, Dave Tyson wrote:

> I seem be able to trigger a consistent crash on a recent install by doing
> heavy disk I/O like deleting a lot of files.
>
> System is an Intel quad-core running :
>
> NetBSD cruncher.anduin.org.uk 7.99.24 NetBSD 7.99.24 (GENERIC) #1: Sat Dec 19
> 11:15:14 GMT 2015
> root%cruncher.anduin.org.uk@localhost:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
>
> Having built about 500 packages I decided after a couple of weeks to clear the
> work files out by:
>
> cd /usr/pkgsrc
> rm -rf */*/work
>
> This triggers a panic - sometimes I get a core dump, but other times the
> machine fails to dump core and just reboots.
>
> panic: kernel diagnostic assertion "vp->v_usecount != 0" failed: file
> "/usr/src/sys/kern/vfs_vnode.c", line 822
> cpu3: Begin traceback...
> vpanic() at netbsd:vpanic+0x13c
> kern_assert() at netbsd:kern_assert+0x4f
> vref() at netbsd:vref+0x74
> getcwd_common() at netbsd:getcwd_common+0x69
> procfs_dir.constprop.0() at netbsd:procfs_dir.constprop.0+0xca
> procfs_getattr() at netbsd:procfs_getattr+0x487
> VOP_GETATTR() at netbsd:VOP_GETATTR+0x34
> vn_stat() at netbsd:vn_stat+0x36
> do_sys_statat() at netbsd:do_sys_statat+0x96
> sys___lstat50() at netbsd:sys___lstat50+0x25
> syscall() at netbsd:syscall+0x9c
> --- syscall (number 441) ---
> 7f7ff3ea99ca:
> cpu3: End traceback...
> uvm_fault(0xfffffe83e5561a20, 0x0, 2) -> e
> fatal page fault in supervisor mode
> trap type 6 code
> 2 rip ffffffff807e901b cs 8 rflags 10286 cr2 84 ilevel 8 rsp fffffe811e765e00
> dumping to dev 0,1 (offset=217511, size=4167225):
> curlwp 0xfffffe83db0b9940 pid 954.17 lowest kstack 0xfffffe811e7622c0
>
> No core dump from that one, but after a reload repeating the same commands to
> clear out the remainder resulted in:
>
> panic: kernel diagnostic assertion "vp->v_usecount != 0" failed: file
> "/usr/src/sys/kern/vfs_vnode.c", line 822
> cpu1: Begin traceback...
> vpanic() at netbsd:vpanic+0x13c
> kern_assert() at netbsd:kern_assert+0x4f
> vref() at netbsd:vref+0x74
> getcwd_common() at netbsd:getcwd_common+0x69
> procfs_dir.constprop.0() at netbsd:procfs_dir.constprop.0+0xca
> procfs_getattr() at netbsd:procfs_getattr+0x487
> VOP_GETATTR() at netbsd:VOP_GETATTR+0x34
> vn_stat() at netbsd:vn_stat+0x36
> do_sys_statat() at netbsd:do_sys_statat+0x96
> sys___lstat50() at netbsd:sys___lstat50+0x25
> syscall() at netbsd:syscall+0x9c
> --- syscall (number 441) ---
> 7f7ff3ea99ca:
> cpu1: End traceback...
> uvm_fault(0xfffffe83f350da18, 0x0, 2) -> e
> ufvatma_faull t
> p(ag0e xfafulftf fifne s8u4p1earvfis4ofre 6mode,
> 0x0, 2) -> e
> dumping to dev 0,1 (offset=217511, size=4167225):
> trap type 6 code 2 rip ffffffff807e901b cs 8 rflags 10286 cr2 84 ilevel 8 rsp
> ffatfaflffaeg8e1 f1auelt0 1inc es0up0e
> rvisor mode
> dump curlwp 0xfffffe83f1718860 pid 1062.9 lowest kstack 0xfffffe81t1rea0p1
> 9t2ycp0e
> 6 code 2 rip ffffffff807e901b cs 8 rflags 10286 cr2 84 ilevel 8 rsp
> fffffe811ded4e00
> curlwp 0xfffffe8418a790a0 pid 96.2 lowest kstack 0xfffffe811ded12c0
>
> Have a core dump for this, but there is obviously some corruption.
> I can make the core dump/symbols available. Worth a pr?
>
> Dave
>
> --
> =========================================
> Phone: 07805784357
> Open Source O/S: www.netbsd.org
> Caving: http://www.wirralcavinggroup.org.uk
> =========================================
>
> !DSPAM:568569b9245851333747418!

+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+