On Monday, October 14, 2013 4:44:28 am Anton Shterenlikht wrote: > > BTW, I see in dmesg: > > Starting ddb. > ddb: sysctl: debug.ddb.scripting.scripts: Invalid argument > /etc/rc: WARNING: failed to start ddb > > What is that about? > > > panic: uma_zfree: Freeing to non free bucket index. > cpuid = 0 > KDB: stack backtrace: > db_trace_self(0x9ffc000000158380) at db_trace_self+0x40 > db_trace_self_wrapper(0x9ffc000000607370) at db_trace_self_wrapper+0x70 > kdb_backtrace(0x9ffc000000ed0e10, 0x9ffc00000058e660, 0x40c, 0x9ffc0000010a44a0) at kdb_backtrace+0xc0 > vpanic(0x9ffc000000dfc468, 0xa0000000e26e0fd8, 0x9ffc000000ef9670, 0x9ffc000000ed0bc0) at vpanic+0x260 > kassert_panic(0x9ffc000000dfc468, 0xe000000015e25f90, 0xe000000015e243e0, 0xe00000027ffd5200) at kassert_panic+0x120 > uma_zfree_arg(0xe00000027ffccfc0, 0xe000000015e243e0, 0x0) at uma_zfree_arg+0x2d0 > g_destroy_bio(0xe000000015e243e0, 0x9ffc0000004ad4a0, 0x30a, 0x30a) at g_destroy_bio+0x30 > g_disk_done(0xe000000015e243e0, 0xe000000015e15d10, 0xe000000012672700, 0x9ffc0000006b18c0) at g_disk_done+0x140 > biodone(0xe000000015e243e0, 0x9ffc000000e0e150, 0xe000000010c24030, 0x0, 0x0, 0x0, 0x9ffc000000066890, 0x614) at biodone+0x180 > dadone(0xe000000012672600, 0xe000000012541000, 0xe000000015e243e0, 0x7) at dadone+0x620 > camisr_runqueue(0xe000000011a2dc00, 0xe000000012541054, 0xe000000012541000, 0x135d) at camisr_runqueue+0x6c0 > camisr(0xe000000011a2dc20, 0xe000000011a2dc00, 0x9ffc000000bee9d0, 0xa0000000e26e1548) at camisr+0x260 > intr_event_execute_handlers(0xe0000000111764a0, 0xe00000001118d998, 0xe000000011191c00, 0x0) at intr_event_execute_handlers+0x280 > ithread_loop(0xe000000011192f00, 0xa0000000e26e1550, 0xe000000011192f14, 0xe00000001118d99c) at ithread_loop+0x1b0 > fork_exit(0x9ffc000000e12a90, 0xe000000011192f00, 0xa0000000e26e1550) at fork_exit+0x120 > enter_userland() at enter_userland > KDB: enter: panic > [ thread pid 12 tid 100015 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2c990,gp ;; > db> > > db> scripts > lockinfo=show locks; show alllocks; show lockedvnods > db> run lockinfo > db:0:lockinfo> show locks > db:0:locks> show alllocks > db:0:alllocks> show lockedvnods > Locked vnodes > > 0xe00000001ab39ba8: tag ufs, type VDIR > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags (VI_ACTIVE) > v_object 0xe00000001cd30900 ref 0 pages 0 > lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 100121) > ino 5467932, on dev da5p1 > > 0xe000000015ed3ba8: tag ufs, type VDIR > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags (VI_ACTIVE) > v_object 0xe00000001cd33e00 ref 0 pages 0 > lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 100092) > ino 5467948, on dev da5p1 > > 0xe00000001ab16938: tag ufs, type VREG > usecount 1, writecount 0, refcount 3 mountedhere 0 > flags (VI_ACTIVE) > v_object 0xe00000001cd98a00 ref 0 pages 1 > lock type ufs: EXCL by thread 0xe000000018494000 (pid 41337, cpdup, tid 100137) > ino 5469420, on dev da5p1 > > 0xe00000001b2503b0: tag ufs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 100092) > ino 5469421, on dev da5p1 > > 0xe00000001ab2a760: tag ufs, type VREG > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VI_ACTIVE) > lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 100121) > ino 5469422, on dev da5p1 > db> > db> script zzz=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; reset > db> run zzz I think 'reset' is going to reset without doing a dump? -- John BaldwinReceived on Tue Oct 15 2013 - 19:19:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:43 UTC