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.... > > -- > David A. Holland > [email protected] -- ----
