On Sat, 3 Jul 2021 at 10:12, Chavdar Ivanov <[email protected]> wrote: > > On Fri, 2 Jul 2021 at 19:27, David Holland <[email protected]> > wrote: > > > > On Fri, Jul 02, 2021 at 07:53:05AM +0100, Chavdar Ivanov wrote: > > > On a system from yesterday, I am still getting > > > > > > Jul 2 04:17:17 ymir /netbsd: [ 49713.7540485] panic: kernel > > > diagnostic assertion "cnp->cn_nameptr[0] != '\0'" failed: file > > > "/home/sysbuild/src/sys/kern/vfs_lookup.c", line 1301 > > > > What file system? And what were you doing? That ought to be impossible > > (obviously, hence the assertion) but since it clearly isn't, knowing > > more about the circumstances will make it easier to figure out what's > > wrong. (In particular, knowing what the path is and if it's exercising > > any of the non-default parsepath calls will be helpful...) > > > > I just went through lookup_fastforward and don't see any way it can > > happen :-( > > I don't know. This is the third time in a row, and yes, it happened > overnight once more, as the two previous crashes. The log file shows, > around the panic: > > > Jul 3 05:34:06 ymir /netbsd: [ 25.5388447] cpu 0: ucode 0x16->0x21 > Jul 3 05:34:06 ymir /netbsd: [ 25.5488456] cpu 2: ucode 0x16->0x21 > Jul 3 05:34:06 ymir /netbsd: [ 25.5488456] cpu 4: ucode 0x16->0x21 > Jul 3 05:34:06 ymir /netbsd: [ 25.5588457] cpu 6: ucode 0x16->0x21 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] panic: kernel diagnostic > assertion "cnp->cn_nameptr[0] != '\0'" failed: file > "/home/sysbuild/src/sys/kern/vfs_lookup.c", line 1301 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] cpu0: Begin traceback... > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] vpanic() at netbsd:vpanic+0x156 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] > __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] namei_tryemulroot() at > netbsd:namei_tryemulroot+0x41a > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] namei() at netbsd:namei+0x29 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] vn_open() at > netbsd:vn_open+0x137 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7347464] do_open() at netbsd:do_open+0xc3 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] do_sys_openat() at > netbsd:do_sys_openat+0x74 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] sys_open() at > netbsd:sys_open+0x24 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] syscall() at > netbsd:syscall+0x196 > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] --- syscall (number 5) --- > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] netbsd:syscall+0x196: > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] cpu0: End traceback... > Jul 3 05:34:06 ymir /netbsd: > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] dumping to dev 168,4 > (offset=8, size=5225879): > Jul 3 05:34:06 ymir /netbsd: [ 4419.7447461] dump WARNING: negative > runtime; monotonic clock has gone backwards > > I don't know why the microcode should be shown downloaded at this > particular moment - I thought this happens only once on boot. > > This time I got a dump though, so if there is something else I could > have a look, I will: > > crash -N netbsd.31 -M netbsd.31.core > Crash version 9.99.86, image version 9.99.86. > crash: _kvm_kvatop(0) > Kernel compiled without options LOCKDEBUG. > System panicked: kernel diagnostic assertion "cnp->cn_nameptr[0] != > '\0'" failed: file "/home/sysbuild/src/sys/kern/vfs_lookup.c", line > 1301 > Backtrace from time of crash is available. > crash> bt > _KERNEL_OPT_GENFB_GLYPHCACHE() at 0 > _KERNEL_OPT_MEMORY_RBFLAGS() at ffff890197de3cc0 > sys_reboot() at sys_reboot > vpanic() at vpanic+0x160 > __x86_indirect_thunk_rax() at __x86_indirect_thunk_rax > namei_tryemulroot() at namei_tryemulroot+0x41a > namei() at namei+0x29 > vn_open() at vn_open+0x137 > do_open() at do_open+0xc3 > do_sys_openat() at do_sys_openat+0x74 > sys_open() at sys_open+0x24 > syscall() at syscall+0x196 > --- syscall (number 5) --- > syscall+0x196: > crash> > > As it was overnight, I wasn't doing anything myself, but in all > occasions there was pkg_rolling-replace going on; upon examination of > the existing work directories, I found that it was building > chat/farstream at the moment of the crash, and that there was an > obviously damaged file - work/.build_makevars.mk - which contained a > fragment of work/farstream-0.2.9/configure , so obviously there is > some mess in the filesystem. After removing ./work (make clean > obviously didn't work for the same reason), farstream built without > any problem, so it is unlikely the problem is connected with the build > process. This laptop was once configured to run samba 4 as a DC, so > there are some 30-40 samba processes going about as well. It also has > ZFS setup, but the sole use at that time of it must have been a single > qemu-nvmm Linux guest having its root disk on a zvol in a pool > residing on a 32GB LITEONIT LMS-32L6M-HP drive....
At least I found out what causes it - I ran /etc/daily and it promptly crashed the same way eventually. I'll repeat it on the console to try to see if something else shows when it happens. > > > > > -- > > David A. Holland > > [email protected] > > > > -- > ---- Chavdar -- ----
