Manuel Bouyer wrote: > 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. >
Yes, WAPBL enabled. I will fill a PR about this if there are no news.
