Re: 9.99.86 HEAD

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Fri, 2 Jul 2021 at 19:27, David Holland <dholland-current%netbsd.org@localhost> 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
> dholland%netbsd.org@localhost



-- 
----