On Fri, Mar 19, 2021 at 04:15:31PM +0000, Stuart Henderson wrote:
> 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.
Yeah, once in a while we see reports of it. It seems to be some nasty
conspiracy between the generic filesystem code, ffs and fsck_ffs.
Maybe even the device (driver) itself is involved. A possible
underlying issue may be that some operation are re-ordered while they
should not.
Now the strange thing is, fsck_ffs *should* be able to repair the
inconsistency, but it appears in some cases it is not, and some bits
on the disk remain to trigger it again.
-Otto
>
>
> > 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
> >
