Re: Panic when deleting large number of files inside DomU

[Roger Pau Monne <roger.pau%citrix.com@localhost>]

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.