On Sun, Jan 31, 2010 at 12:15:58PM -0701, Jeff Ross wrote:
> On Sat, 30 Jan 2010, Bob Beck wrote:
>
> > Ooooh. nice one. Obviously ami couldn't get memory mappings and freaked
> > out.
> >
> > While not completely necessary, I'd love for you to file that whole
> > thing into sendbug() in a pr so we don't
> > forget it. but that one I need to pester krw, art, dlg, and maybe
> > marco about what ami is doing.
> >
> > note that the behaviour you see wrt free memory dropping but not
> > hitting swap is what I expect.
> > basically that makes the buffer cache subordinate to working set
> > memory between 10 and 90% of
> > physmem. the buffer cache will throw away pages before allowing the
> > system to swap.
> >
> > Drop it back to 70% and tell me if you still get the same panic
> > please. and if you have a fixed test
> > case that reproduces this on your machine ( a load generator for
> > postgres with clients) I'd love to
> > have a copy in the pr as well.
>
> 70% produces the same panic.
>
> panic: pmap_enter: no pv entries available
> Stopped at Debugger+0x4: leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS
> PANIC!
> IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS,
> TOO.
> DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
> ddb{0}> trace
> Debugger(7149,dfe3ede8,d08edf18,c,0) at Debugger+0x4
> panic(d077d740,0,7000,d08ad6e0,ffffffff) at panic+0x55
> pmap_enter(d08f3520,e0031000,7149000,3,13) at pmap_enter+0x2e5
> _bus_dmamem_map(d0875c40,d505fc44,1,6344,d505fc58,1,dfe3eebc,1) at
> _bus_dmamem_map+0x9c
> ami_allocmem(d49b5800,6344,20,d0753ddc) at ami_allocmem+0x92
> ami_mgmt(d49b5800,a1,4,0,0,6344,d49cd000,1) at ami_mgmt+0x268
> ami_refresh_sensors(d49b5800,da987028,da987050,80000000,da987028) at
> ami_refresh_sensors+0x25
> sensor_task_work(d49b3d80,0,50,200286) at sensor_task_work+0x1f
> workq_thread(d0863100) at workq_thread+0x32
> Bad frame pointer: 0xd0a32e78
> ddb{0}>
>
> I'll skip the ps for this go round since it should be pretty much the same
> and go directly to sendbug, including the pg_bench script I use to trigger
> it.
pv entries seem to come from kmem_map. My guess is that this map is
filled (it's interrupt safe, but pretty small). Caller should allow it
to fail though: IO can be retried later.
I don't think you're actually running out of free memory.
Why are the pventries allocated from the kmem_map anyway? I think they
should be allocated using the uvm_km_getpage instead. Or even better,
from a pvpool like amd64.
Ciao,
--
Ariane
