Agreed...I'm not convinced it was due to being hosted on VMM...just wanted to include that as a data point (perhaps that detail is stressed too much here).
I'm looking/learning about the "missing dquot" panic message now (brushing up on CVS, etc). :) After reboot, the filesystem fsck'd, and all seems to be well at this point. On Tue, Mar 31, 2020 at 6:09 AM Pratik Vyas <[email protected]> wrote: > > * Bryan Stenson <[email protected]> [2020-03-31 05:57:46 +0000]: > > >>Synopsis: panic on vm hosted with VMM - missing dquot > >>Category: unknown > >>Environment: > > System : OpenBSD 6.6 > > Details : OpenBSD 6.6-current (GENERIC) #85: Sun Mar 29 > >10:50:36 MDT 2020 > > > >[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > >>Description: I noticed my VM was unresponsive, and upon accessing via > >>console, received the ddb prompt. > > > >>How-To-Repeat: unknown > > > >>Fix: unknown > > > >server9$ vmctl console 16 > >Connected to /dev/ttypg (speed 115200) > >https://www.openbsd.org/ddb.html describes the minimum info required in bug > >reports. Insufficient info makes it difficult to find and fix bugs. > >ddb> trace > >db_enter() at db_enter+0x10 > >panic(ffffffff81c52ce1) at panic+0x128 > >chkdquot(fffffd80363fa968) at chkdquot+0xac > >ufs_quota_alloc_blocks2(fffffd80363fa968,20,fffffd801b174918,0) at > >ufs_quota_al > >loc_blocks2+0x2f > >ffs_alloc(fffffd80363fa968,23,230648,4000,fffffd801b174918,ffff8000149cd458) > >at > > ffs_alloc+0x11e > >ffs1_balloc(fffffd80363fa968,8c000,50,fffffd801b174918,1,ffff8000149cd550) > >at f > >fs1_balloc+0xc46 > >ffs_write(ffff8000149cd5c0) at ffs_write+0x262 > >VOP_WRITE(fffffd803aff95c0,ffff8000149cd650,3,fffffd801b174918) at > >VOP_WRITE+0x > >4f > >ktrwriteraw(ffff8000149ce4f0,fffffd803aff95c0,fffffd801b174918,ffff8000149cd710 > >,ffff8000149cd6f0) at ktrwriteraw+0xf3 > >ktrsyscall(ffff8000149ce4f0,3,18,ffff8000149cd7d0) at ktrsyscall+0x20c > >syscall(ffff8000149cd8a0) at syscall+0x1e8 > >Xsyscall() at Xsyscall+0x128 > >end of kernel > >end trace frame: 0x7f7ffffd6300, count: -12 > >ddb> > > > > not sure if this is vmm (unless it's due to disk corruption?). Anything > else wrong after reboot? > > > -- > Pratik
