tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

pegasosII hung with new kernel - page daemon spinning



hi folks.


testing out the ppc intr fix i ran 'cvs up -dPA' in my src tree and
a short while later, my system has soft-locked up.  it appears that
the page daemon is cpu spinning not giving up the cpu.  but there's
plenty of free pages and etc so it shouldn't be rurnning all the
time:

db> show uvmexp
Current UVM status:
  pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
, ncolors=1  123256 VM pages: 6215 active, 3035 inactive, 0 wired, 96063 free
  pages  2360 anon, 5034 file, 1856 exec
  freemin=256, free-target=341, wired-max=41085
  cpu0:
    faults=46153, traps=48555, intrs=7562381, ctxswitch=58644
    softint=1100268, syscalls=0
  fault counts:
    noram=0, noanon=0, pgwait=0, pgrele=0
    ok relocks(total)=488(488), anget(retrys)=13157(0), amapcopy=5069
    neighbor anon/obj pg=11116/81215, gets(lock/unlock)=21061/488
    cases: anon=8239, anoncow=4906, obj=18107, prcopy=2954, przero=7119
  daemon and swap counts:
    woke=1, revs=2, scans=0, obscans=0, anscans=0
    busy=0, freed=0, reactivate=0, deactivate=3036
    pageouts=0, pending=0, nswget=0
    nswapdev=1, swpgavail=131072
    swpages=131072, swpginuse=0, swpgonly=0, paging=0

ie, there's 3/4 (of 512MB) memory free, nothing in swap used... no
really clear idea why this is spinning.  the several back traces i
see from pagedaemon (which is always the active thread when i enter
ddb) look like this:

[ .. enters ddb .. ]
0xaa291df0: at mutex_enter+0x28c
0xaa291e30: at pool_drain+0x48
0xaa291e50: at uvm_pageout+0x350
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

0xaa291e30: at mutex_exit+0x180
0xaa291e50: at uvm_pageout+0x314
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

0xaa291d90: at mutex_exit+0x150
0xaa291db0: at pool_cache_invalidate+0xb8
0xaa291dd0: at pool_reclaim+0xa0
0xaa291e30: at pool_drain+0x94
0xaa291e50: at uvm_pageout+0x350
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

0xaa291e10: at mutex_enter+0x28c
0xaa291e50: at uvm_pageout+0x4dc
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

0xaa291e10: at mutex_exit+0x180
0xaa291e30: at pool_drain+0xc4
0xaa291e50: at uvm_pageout+0x350
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

0xaa291db0: at mutex_exit+0x150
0xaa291dd0: at pool_reclaim+0x264
0xaa291e30: at pool_drain+0x94
0xaa291e50: at uvm_pageout+0x350
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

0xaa291e10: at mutex_enter+0x28c
0xaa291e50: at uvm_pageout+0xc4
0xaa291f20: at cpu_lwp_bootstrap+0xc
0xaa291fe8: at 0xfffffffc

(they're all mutex_enter/exit at the part before entering ddb
because the interrupt delivery happens here.)

any ideas?  i'll keep the box spinning for a little while in
case someone has ddb-capable ideas.  thanks.


.mrg.


Home | Main Index | Thread Index | Old Index