> On 16 Mar 2021, at 21:17, Mischa <obs...@high5.nl> wrote: > 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.
Was running pkg_add and during extraction of automake the VM hanged, with the same panic/trace. root@server14:~ # vmctl console vm11 Connected to /dev/ttyp8 (speed 115200) ddb> show panic ffs_valloc: dup alloc ddb> trace db_enter() at db_enter+0x10 panic(ffffffff81dc5a29) at panic+0x12a ffs_inode_alloc(fffffd8035819e20,41ed,fffffd803f7bb780,ffff800014e84ac8) at ffs _inode_alloc+0x442 ufs_mkdir(ffff800014e84b20) at ufs_mkdir+0x9e VOP_MKDIR(fffffd8038c3b820,ffff800014e84c58,ffff800014e84ca8,ffff800014e84b88) a t VOP_MKDIR+0x50 domkdirat(ffff8000ffff8ef0,ffffff9c,f7e8cefbd80,1ff) at domkdirat+0xf6 syscall(ffff800014e84e20) at syscall+0x315 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7ffffc6480, count: -8 ddb> After running fsck the VM isn’t right anymore. reordering libraries:install: unknown group bin install: unknown group bin failed. install: unknown group utmp starting early daemons: syslogd pflogd ntpd. starting RPC daemons:. savecore: no core dump checking quotas: done. kvm_mkdb: can't find kmem group: Undefined error: 0 chown: group is invalid: wheel clearing /tmp Will spin a non-derived VM to see if this makes a difference. Mischa
