Re: Panic when deleting large number of files inside DomU

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Sep 19, 2012 at 11:51:24AM +0200, Roger Pau Monne wrote:
> Manuel Bouyer wrote:
> > On Fri, Sep 14, 2012 at 03:19:19AM -0700, Brian Buhrow wrote:
> >> } FWIW, I've just seen this on a native i386 system while running a
> >> } pkg_delete. No WAPBL on this system.
> >>
> >>    hello.  What version of NetBSD?
> > 
> > 6.0_RC1
> 
> A little more info about this, while doing a git clone of a very big
> project inside a Xen DomU I also got a crash, this time I was not able
> to get to ddb, this was printed on the console:
> 
> dmode 7274 mode 7274 dgen 61006465 gen 61006465
> size 7474615f68736168 blocks 6269727474610072
> ino 113648 ipref 113600
> panic: ffs_valloc: dup alloc
> fatal breakpoint trap
> 
> However, I've been able to get a kernel trace with gdb:
> 
> Thread 1:
> 
> #0  0xffffffff80130c82 in x86_pause ()
> #1  0xffffffff801f70c1 in _kernel_lock ()
> #2  0xffffffff801edd7d in kevent1 ()
> #3  0xffffffff801edf01 in sys___kevent50 ()
> #4  0xffffffff8032c2e4 in syscall ()
> #5  0xffffffff8010221d in Xsyscall ()
> 
> Thread 2:
> 
> #0  0xffffffff80130adb in x86_lfence ()
> #1  0xffffffff803ab99d in spllower ()
> #2  0xffffffff8020c1f6 in sleepq_abort ()
> #3  0xffffffff8020e5a7 in tsleep ()
> #4  0xffffffff803ad381 in xb_read ()
> #5  0xffffffff803aea52 in xenbus_thread ()
> #6  0xffffffff80102327 in lwp_trampoline ()
> #7  0x0000000000000000 in ?? ()
> 
> Thread 3:
> 
> #0  0xffffffff80130c82 in x86_pause ()
> #1  0xffffffff801f70c1 in _kernel_lock ()
> #2  0xffffffff8030c224 in bdev_strategy ()
> #3  0xffffffff803049a8 in spec_strategy ()
> #4  0xffffffff803a83a6 in VOP_STRATEGY ()
> #5  0xffffffff80176dc6 in genfs_do_io ()
> #6  0xffffffff801790a5 in genfs_gop_write ()
> #7  0xffffffff801786cf in genfs_do_putpages ()
> #8  0xffffffff803a86d4 in VOP_PUTPAGES ()
> #9  0xffffffff8039799d in vflushbuf ()
> #10 0xffffffff8016a0a2 in ffs_full_fsync ()
> #11 0xffffffff8016a1eb in ffs_fsync ()
> #12 0xffffffff803a7c77 in VOP_FSYNC ()
> #13 0xffffffff8031e565 in sched_sync ()
> #14 0xffffffff80102327 in lwp_trampoline ()
> #15 0x0000000000000000 in ?? ()
> 
> Thread 4:
> 
> #0  0xffffffff80130c82 in x86_pause ()
> #1  0xffffffff801f70c1 in _kernel_lock ()
> #2  0xffffffff8014b220 in intr_biglock_wrapper ()
> #3  0xffffffff80103cb7 in Xresume_xenev6 ()
> #4  0x0000000018041969 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> This was on a clean install of RC1, using FFSv2.

With, or without WAPBL ? If you choose the default parameters,
you almost certainly have WAPBL enabled.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--