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
