>Number:         35042
>Category:       kern
>Synopsis:       panic in vmem system (missing splfoo?)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 12 18:40:00 +0000 2006
>Originator:     Manuel Bouyer
>Release:        NetBSD 4.99.3
>Organization:
	http://www.lip6.fr
>Environment:
System: NetBSD rondo.lip6.fr 4.99.3 NetBSD 4.99.3 (XEN3_DOM0) #3: Thu Nov 9 23:47:46 CET 2006 bouyer@blues.lip6.fr:/Volumes/data/bouyer/tmp/i386/obj/Volumes/data/bouyer/current/src/sys/arch/i386/compile/XEN3_DOM0 i386
Architecture: i386
Machine: i386
>Description:
	My Xen3 dom0 paniced twice today; each time in vmem(9). Looking at
	backtrace I suspect a missing splfoo() somewhere: we get an interrupt
	which ends up calling vmem_alloc() while we are in vmem_free().
	Another Xen3 user reported a similar panic on port-xen:
	http://mail-index.netbsd.org/port-xen/2006/11/08/0004.html

panic: kernel diagnostic assertion "pcg->pcg_avail != 0" failed: file "/Volume
s/data/bouyer/current/src/sys/kern/subr_pool.c", line 1988
Stopped in pid 1055.2 (qemu-dm) at      netbsd:cpu_Debugger+0x4:        popl  
  %
ebp
db> tr
cpu_Debugger(c084a8c5,cba655e0,be42d463,cba65638,c04d73c5) at netbsd:cpu_Debugger+0x4
panic(c08ab718,c0813ea5,c082a846,c087e8b8,7c4) at netbsd:panic+0x155
__assert(c0813ea5,c087e8b8,7c4,c082a846,b2d1fd26) at netbsd:__assert+0x2e
pool_cache_get_paddr(c0922160,0,0,cba65668,c04d8083) at netbsd:pool_cache_get_paddr+0x15f
bt_alloc(c0e29000,4,22,cba65668,c03d87a2) at netbsd:bt_alloc+0x24
vmem_xalloc(c0e29000,4,1,0,0) at netbsd:vmem_xalloc+0xdb
vmem_alloc(c0e29000,4,1002,3,0) at netbsd:vmem_alloc+0xd2
xen_shm_map(4,1,c0cc7b00,c0cc7afc,c0cc7b40) at netbsd:xen_shm_map+0x56
xbdback_co_flush(c13e2f00,c13e2f00,1f439cf0,9d9,c0e0e5e0) at netbsd:xbdback_co_flush+0x80
xbdback_trampoline(a53da4,0,cba659c4,c04dfb6d,c13e2f00) at netbsd:xbdback_trampoline+0x36
xbdback_evthandler(c13e2f00,cba65a10,cba659fc,c,cb8ac01c) at netbsd:xbdback_evthandler+0x25
evtchn_do_event(10,cba65a10,cba65a3e,135b,cba65a5c) at netbsd:evtchn_do_event+0xbd
do_hypervisor_callback(cba65a10,0,11,c1450031,cba60011) at netbsd:do_hypervisor_callback+0xfa
hypervisor_callback(c0922160,c1451380,ffffffff,1001,c145132c) at netbsd:hypervisor_callback+0x64
bt_free(c0c91000,308,cba65acc,c043c20e,308) at netbsd:bt_free+0x1f
vmem_xfree(c0c91000,cb3f1400,308,c0424431,cb3f1400) at netbsd:vmem_xfree+0x190
kmem_free(cb3f1400,308,308,0,0) at netbsd:kmem_free+0x30
sa_upcall_userret(cb7cc008,100,cba65c5c,cb7cc008,cb7cc008) at netbsd:sa_upcall_u
serret+0x28d
upcallret(cb7cc008,132,c0829e2c,0,0) at netbsd:upcallret+0x5f
sa_yield(cb7cc008,308,0,cb86c658,cb6b3f28) at netbsd:sa_yield+0xe9
sys_sa_yield(cb7cc008,cba65c48,cba65c68,1,cba65c40) at netbsd:sys_sa_yield+0x7b
syscall_plain() at netbsd:syscall_plain+0xb3
--- syscall (number 334) ---

	
>How-To-Repeat:
	run a Xen 3.0.3 dom0 with lots of disk activity in domU ?
>Fix:
	Unkown