On 13 Mar at 09:17, Otto Moerbeek <o...@drijf.net> wrote: > On Sat, Mar 13, 2021 at 12:08:52AM -0800, Mike Larkin wrote: > > On Wed, Mar 10, 2021 at 08:30:32PM +0100, Mischa wrote: > > > On 10 Mar at 18:59, Mike Larkin <mlar...@nested.page> wrote: > > > > On Wed, Mar 10, 2021 at 03:08:21PM +0100, Mischa wrote: > > > > > Hi All, > > > > > > > > > > Currently I am running 6.9-beta on one of my hosts to test > > > > > veb(4)/vport(4). > > > > > > > > > > root@server14:~ # sysctl kern.version > > > > > kern.version=OpenBSD 6.9-beta (GENERIC.MP) #385: Mon Mar 8 12:57:12 > > > > > MST 2021 > > > > > > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > > On order to add some load to the system I created 41 additional VMs > > > > > based on a single qcow2 base image. > > > > > A couple of those VMs crashed with the following ddb output. > > > > > > > > > > ddb> show panic > > > > > ffs_valloc: dup alloc > > > > > ddb> trace > > > > > db_enter() at db_enter+0x10 > > > > > panic(ffffffff81dc0709) at panic+0x12a > > > > > ffs_inode_alloc(fffffd80269831e0,8180,fffffd803f7bb540,ffff800014e1e3e8) > > > > > at ffs > > > > > _inode_alloc+0x442 > > > > > ufs_makeinode(8180,fffffd8026a386a0,ffff800014e1e6e0,ffff800014e1e730) > > > > > at ufs_m > > > > > akeinode+0x7f > > > > > ufs_create(ffff800014e1e490) at ufs_create+0x3c > > > > > VOP_CREATE(fffffd8026a386a0,ffff800014e1e6e0,ffff800014e1e730,ffff800014e1e4f0) > > > > > at VOP_CREATE+0x4a > > > > > vn_open(ffff800014e1e6b0,10602,180) at vn_open+0x182 > > > > > doopenat(ffff800014e8a518,ffffff9c,70e0e92a500,10601,1b6,ffff800014e1e8b0) > > > > > at d > > > > > oopenat+0x1d0 > > > > > syscall(ffff800014e1e920) at syscall+0x315 > > > > > Xsyscall() at Xsyscall+0x128 > > > > > end of kernel > > > > > end trace frame: 0x7f7ffffe5000, count: -10 > > > > > > > > > > Mischa > > > > > > > > > > > > > Probably not vmm(4) related but thanks for reporting! > > > > > > Could it be qcow2 related? or is this general disk? At least that is what > > > I think ffs_ is. :) > > > > > > Mischa > > > > > > > likely completely unrelated to anything vmd(8) is doing. > > > > Appart form kernel/ffs bugs, a dup alloc can also be caused by an > inconsistent fs. Please run a *forced* (-f) fsck on the fs. (after > unmounting of course). > > -Otto
Thanx Otto, that indeed did the trick. It hasn't happened since and veb/vport seems to hold well. Mischa
