On Mon, Jun 04, 2018 at 01:23:53AM +0200, Alexander Bluhm wrote:
> On my amd64 regress machine I see a witness_warn panic now.

It is triggered by /usr/src/regress/sys/kern/mount.  With visa@'s
improved stack trace I see:

======== run-regress-unmount-busy ========
cp -r /usr /mnt/regress-mount &
sleep 5
sync
sleep 10
rm -rf /mnt/regress-mount/usr &
sleep .1
umount -f /mnt/regress-mount
userret: returning with the following locks helfsck -y /dev/rvnd:d0a 2>&1 | tee 
f
esck-clean.log
xclusive rrwlock inode r = 0 (0xffffff023d492b48) locked @ 
/usr/src/sys/ufs/ufs/ufs_vnops.c:1559
#0  witness_lock+0x254
#1  _rw_enter+0x29b
#2  _rrw_enrm: terfts_read: +0x3e
#3  VOP_LOCK+0x3d
#4  vn_lock+0x34
#5  vget+0xf7
#6  cache_lookup+0x217
#7  ufs_lookup+0x112
#8  VOP_LOOKUP+0x4f
#9  vfs_lookup+0x27e
#directory          No such file or 
10 namei+0x226
#11 vn_open+0xcf
#12 doopenat+0x1af
#13 syscall+0x32a
#14 Xsyscall_untramp+0xc0
panic: witness_warn
Stopped at      db_enter+0x12:  popq    %r11
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
*340900  45836      0    0x100003          0    2  cp
db_enter() at db_enter+0x12
panic() at panic+0x138
witness_warn(4daf31f665ef77b2,ffff800021f74290,ffff8000ffff6960) at witness_war
n+0x4fb
userret(184acb3033f01432) at userret+0x1a0
syscall(e44e1a254de07323) at syscall+0x423
Xsyscall_untramp(6,0,0,0,0,2) at Xsyscall_untramp+0xc0
end of kernel
end trace frame: 0x7f7ffffd19b0, count: 9
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{2}> show locks
exclusive rrwlock inode r = 0 (0xffffff023d492b48) locked @ /usr/src/sys/ufs/uf
s/ufs_vnops.c:1559
#0  witness_lock+0x254
#1  _rw_enter+0x29b
#2  _rrw_enter+0x3e
#3  VOP_LOCK+0x3d
#4  vn_lock+0x34
#5  vget+0xf7
#6  cache_lookup+0x217
#7  ufs_lookup+0x112
#8  VOP_LOOKUP+0x4f
#9  vfs_lookup+0x27e
#10 namei+0x226
#11 vn_open+0xcf
#12 doopenat+0x1af
#13 syscall+0x32a
#14 Xsyscall_untramp+0xc0
ddb{2}> show register
rdi               0xffffffff81ca2888    kprintf_mutex+0x10
rsi                              0x8
rbp               0xffff800021f740e0
rbx               0xffff800021f74180
rdx               0xffffffff81bfddd6    intel_hpll_vco.cl_vco+0x3e6
rcx                            0x201
rax                              0x1
r8                0xffff800021f740b0
r9                0x8080808080808080
r10               0x3df1125987f3e8ca
r11               0x1a70d75cd6a8e458
r12                     0x3000000008
r13               0xffff800021f740f0
r14                            0x100
r15               0xffffffff81c0463f    nviic_ids+0x7df
rip               0xffffffff81767d82    db_enter+0x12
cs                               0x8
rflags                         0x202
rsp               0xffff800021f740d8
ss                              0x10
db_enter+0x12:  popq    %r11
ddb{2}> 

All other CPUs are in the idle thread.

bluhm

Reply via email to