kern/48372: sunblade 2500 hangs under memory pressure -- loop between uvm/pool/vmem

[mrg%eterna.com.au@localhost]

>Number:         48372
>Category:       kern
>Synopsis:       sunblade 2500 hangs under memory pressure -- loop between 
>uvm/pool/vmem
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 08 22:40:00 +0000 2013
>Originator:     matthew green
>Release:        NetBSD 6.1_STABLE
>Organization:
people's front against (bozotic) www (softwar foundation)
>Environment:
        
        
System: NetBSD splode.eterna.com.au 6.1_STABLE NetBSD 6.1_STABLE (_splode_) #1: 
Thu Jul 11 19:09:23 EST 2013 
mrg%splode.eterna.com.au@localhost:/var/obj/sparc64/usr/src/sys/arch/sparc64/compile/_splode_
 sparc64
Architecture: sparc64
Machine: sparc64
>Description:

twice after being up about 6 days my sunblade 2500 with one cpu
and 4GB of ram has hung.  breaking into ddb on the console shows
that a loop was occuring between uvm, pool and vmem.

"show uvm" says that there is only 1 free page, and the bt is:

db{0}> bt
intr_list_handler(59c86d0, a, e0017ed0, 330, 1203f20, 0) at 
netbsd:intr_list_handler+0x10
sparc_interrupt(0, a, 400cc000, 575dec0, 0, 0) at netbsd:sparc_interrupt+0x22c
mutex_spin_enter(18aac80, ff070000000001, ffffffffffffffff, 4000001, 0, 0) at 
netbsd:mutex_spin_enter+0xa0
bt_refill(18abd18, 1002, ff070000000001, 874061e8, 0, 0) at 
netbsd:bt_refill+0x100
vmem_xalloc(18abd18, 2000, 2000, 0, 0, 0) at netbsd:vmem_xalloc+0x6c
vmem_alloc(18abd18, 2000, 1002, 87405d68, 0, 0) at netbsd:vmem_alloc+0x94
pool_page_alloc_meta(18a93f0, 2, ff070000000001, 87406aa8, 0, 0) at 
netbsd:pool_page_alloc_meta+0x2c
pool_grow(18a93f0, 2, 2000, 0, 0, 0) at netbsd:pool_grow+0x1c
pool_get(18a94a8, 2, ff070000000001, 330, 0, 0) at netbsd:pool_get+0x3c
pool_cache_put_slow(18ad840, a, 400cc000, 575dec0, 0, 0) at 
netbsd:pool_cache_put_slow+0x160
pool_cache_put_paddr(18ad600, 400cc000, ffffffffffffffff, 4000001, 0, 0) at 
netbsd:pool_cache_put_paddr+0xa4

[ this repeats 30 more times
uvm_km_kmem_alloc(c, 2000, 0, 87411628, 0, 0) at netbsd:uvm_km_kmem_alloc+0x104
vmem_xalloc(18abd18, 18abfb0, 2000, 0, 0, 0) at netbsd:vmem_xalloc+0x8ac
vmem_alloc(18abd18, 2000, 1002, 874117c8, ff7fffff, ffdfffff) at 
netbsd:vmem_alloc+0x94
pool_page_alloc_meta(18a93f0, 2, ff070000000001, 13, 0, 0) at 
netbsd:pool_page_alloc_meta+0x2c
pool_grow(18a93f0, 2, 59c2000, 13, 7d, 0) at netbsd:pool_grow+0x1c
pool_get(18a94a8, 2, 59c2000, 5, 10c2660, ffffffffffffffff) at 
netbsd:pool_get+0x3c
pool_cache_put_slow(57b7780, 0, 28f50940, 4, 0, 0) at 
netbsd:pool_cache_put_slow+0x160
pool_cache_put_paddr(57b7540, 28f50940, ffffffffffffffff, 201b, 0, 0) at 
netbsd:pool_cache_put_paddr+0xa4
]

ffs_reclaim(0, 59c2000, 59c2000, 0, 0, 0) at netbsd:ffs_reclaim+0xec
VOP_RECLAIM(28f54e70, 1, 0, 59c2000, 0, 0) at netbsd:VOP_RECLAIM+0x28
vclean(28f54e70, 8, 0, 0, ff7fffff, ffdfffff) at netbsd:vclean+0x134
cleanvnode(1884500, 0, 64, 6, 28f54e94, 1884500) at netbsd:cleanvnode+0xc4
vdrain_thread(59c2000, 59c2000, 0, 1c05d38, 7d, 0) at netbsd:vdrain_thread+0x90
lwp_trampoline(f005d730, 113800, 113c00, 111880, 111ce0, 1117f8) at 
netbsd:lwp_trampoline+0x8


>How-To-Repeat:

        not really sure.  the second hang was during a backup
        run, but the first hang was an hour or two after that
        had finished.

>Fix:

>Unformatted: