Yesterday, I received one suggestion from Chuck.  He sent me
an e-mail directly.  So I don't include it here but write
what he says.  He said I might be hitting the limit on the
"UVM amap" allocation, and suggested that I should try to
eliminate a KMEMSTATS definition from my configuration file.

Currently, my system which has 128 MB memories works fine
after eliminating the KMEMSTATS definition.  I rebuilt my
system about 2 hours ago.  Before the rebuilding, the system
was halted every time when I tried to link a mozilla
statically.  But now it works fine.  Thanks a lot Chuck.
And thank you very much the writing the UVM.


I don't understand what the limit on the "UVM amap"
allocation is.  Is it well known problem?  If so, why does
the limit make KMEMSTATS wrong?  In addition, the system
without UVM works fine with this KMEMSTATS.

The system looks like good without KMEMSTATS.  But the
system with KMEMSTATS should work, doesn't it?  If anyone
want to know more information to fix it, I'll help you.
And I'll try to understand the UVM.


   On May 15, 16:20, matthew green wrote:
   > Subject: Re: UVM deadlock?
   > 
   > please run this from ddb:
   > db> call uvmhist_dump(pdhist)
   > db> call uvmhist_dump(maphist)

Thank you.  I got following stuff.  uvmhist_dump(maphist) is
an interesting dump.

db> call uvmhist_dump(maphist)
895262779.231226 amap_copy#387953:   (map=0xf08c0000, entry=0xf09c2cc0, waitf=1)
895262779.231231 amap_copy#387953:   amap=0xf0a1f400, ref=2, must copy it
895262779.231236 amap_copy#387953:   amap_alloc1 failed
895262779.231266 uvm_pageout#0:   <<SLEEPING>>
895262779.231283 uvm_map_lookup_entry#9891086: called!
895262779.231287 uvm_map_lookup_entry#9891086: (map=0xf08c0000,addr=0xefbfc000,ent=0xf7dcef50)
895262779.231292 uvm_map_lookup_entry#9891086: <- got it via hint (0xf09c2cc0)
895262779.231297 amap_copy#387954: called!
895262779.231302 amap_copy#387954:   (map=0xf08c0000, entry=0xf09c2cc0, waitf=1)
895262779.231307 amap_copy#387954:   amap=0xf0a1f400, ref=2, must copy it
895262779.231312 amap_copy#387954:   amap_alloc1 failed
895262779.231342 uvm_pageout#0:   <<SLEEPING>>
895262779.231358 uvm_map_lookup_entry#9891087: called!
895262779.231363 uvm_map_lookup_entry#9891087: (map=0xf08c0000,addr=0xefbfc000,ent=0xf7dcef50)
895262779.231368 uvm_map_lookup_entry#9891087: <- got it via hint (0xf09c2cc0)
895262779.231374 amap_copy#387955: called!
895262779.231378 amap_copy#387955:   (map=0xf08c0000, entry=0xf09c2cc0, waitf=1)
895262779.231383 amap_copy#387955:   amap=0xf0a1f400, ref=2, must copy it
895262779.231388 amap_copy#387955:   amap_alloc1 failed
895262779.231417 uvm_pageout#0:   <<SLEEPING>>
...
<<Removed some stuff>>
...
895262779.232094 uvm_pageout#0:   <<SLEEPING>>
895262779.232112 uvm_map_lookup_entry#9891097: called!
895262779.232116 uvm_map_lookup_entry#9891097: (map=0xf08c0000,addr=0xefbfc000,ent=0xf7dcef50)
895262779.232121 uvm_map_lookup_entry#9891097: <- got it via hint (0xf09c2cc0)
895262779.232126 amap_copy#387965: called!
895262779.232130 amap_copy#387965:   (map=0xf08c0000, entry=0xf09c2cc0, waitf=1)
895262779.232135 amap_copy#387965:   amap=0xf0a1f400, ref=2, must copy it
895262779.232141 amap_copy#387965:   amap_alloc1 failed
895262779.232170 uvm_pageout#0:   <<SLEEPING>>
0x9
db> call uvmhist_dump(pdhist)
895262779.228449 uvm_pageout#0:   <<WOKE UP>>
895262779.228454 uvm_pageout#0:   free/ftarg=86/85, inact/itarg=9385/9373
895262779.228525 uvm_pageout#0:   <<WOKE UP>>
895262779.228530 uvm_pageout#0:   free/ftarg=86/85, inact/itarg=9385/9373
895262779.228601 uvm_pageout#0:   <<WOKE UP>>
895262779.228606 uvm_pageout#0:   free/ftarg=86/85, inact/itarg=9385/9373
...
<<Removed many almost same stuff>>

-- Kazushi
You two ought to be more careful--your love could drag on for years and years.