On 2021/03/19 17:05, Jan Klemkow wrote:
> Hi,
>
> I had the same issue a few days ago a server hardware of mine. I just
> ran 'cvs up'. So, it looks like a generic bug in FFS and not related to
> vmm.
This panic generally relates to filesystem corruption. If fsck doesn't
help then recreating which filesystem is triggering it is usually needed.
> OpenBSD 6.9-beta (GENERIC.MP) #396: Thu Mar 11 19:15:56 MST 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> ciao,
> Jan
>
> ddb{2}> show panic
> ffs_valloc: dup alloc
>
> ddb{2}> trace
> db_enter() at db_enter+0x10
> panic(ffffffff81dda170) at panic+0x12a
> ffs_inode_alloc(fffffd8a1acb50f0,81a4,fffffd8c3f7ba120,ffff8000229d3088) at
> ffs
> _inode_alloc+0x442
> ufs_makeinode(81a4,fffffd8a8a498940,ffff8000229d3380,ffff8000229d33d0) at
> ufs_m
> akeinode+0x7f
> ufs_create(ffff8000229d3130) at ufs_create+0x3c
> VOP_CREATE(fffffd8a8a498940,ffff8000229d3380,ffff8000229d33d0,ffff8000229d3190)
> at VOP_CREATE+0x4a
> vn_open(ffff8000229d3350,602,1a4) at vn_open+0x182
> doopenat(ffff800022915500,ffffff9c,cc7a0280ad0,601,1b6,ffff8000229d3550) at
> doo
> penat+0x1cd
> syscall(ffff8000229d35c0) at syscall+0x389
> Xsyscall() at Xsyscall+0x128
> end of kernel
> end trace frame: 0x7f7ffffc5520, count: -10
>
> ddb{2}> ps
> PID TID PPID UID S FLAGS WAIT COMMAND
> *56226 366608 70629 0 7 0x100003 cvs
>
