Re: Panic when deleting large number of files inside DomU

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

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.