On Fri, 08 May 1998 13:35:33 -0700,
Jason Thorpe <thorpej@nas.nasa.gov> wrote:
> On Sat, 09 May 1998 03:49:14 +0900 
>  Ken Nakata <kenn@synap.ne.jp> wrote:
>  > OK.  Well, I wasn't suggesting those who are having trouble with UVM
>  > should build without it.  If I were, I wouldn't be working with Scott
>  > and Chuck to resolve my UVM related panic ;-)
> 
> ...can you please reiterate what that was?  I seem to remember that
> it was "out of space in kmem_map"?  If it is, then the default
> NKMEMCLUSTERS probably needs to be cranked up.

Unfortunately, it turned out to be much more than that.  I tried 1024,
2048, and 4096 (the default is 512 on mac68k), but whenever Emacs 20.2
(built right out of the box from pkgsrc) tries to exec something, the
kernel would panic and drop into the debugger.

It takes increasingly longer to panic after everything freezes, as I
increase NKMEMCLUSTERS.  It seems as though there's an infinite loop
somewhere, malloc()ing kmem until malloc() finally fails and panics.

Stack trace shows:

_Debugger(...)
_panic(...)
_malloc(3a,1f,0,ffffc000,ffff0000)
_uvm_map_clip_start(1518500,1bff040,0)+24
_amap_copy(1518500,1bff040,1,1,ffffc000,ffffc001)+81
_uvmfault_amapcopy(acdc98,ffffc000,8,1518500,fffffffe)+134
_uvm_falut(1518500,ffffc000,0,3)+1e8
_trap(8,481,ffffcb58)+554
faultstkadj(acdee8,acde2c,ffffcb58,5730000)+0
_sys_execve(1538800,cdef88,cdef80)+324
_syscall(3b)+13e
_trap0()+e

Following Chuck's suggestion, I've done this, too:

db> show map *kmem_map
MAP 0x13b194: [0x1400000->0x1c00000]
	#ent=1,sz=8388608,ref=2,main=T,version=1809
	pmap=0x14dd8c(resident=3947)
db>

This was done on a kernel with NKMEMCLUSTERS=2048 (i.e. 8M bytes), and
as you can see, it's completely filled.

I'm starting to suspect that yet another GCC optimization bug or
something is preventing some loop from exitting properly.  Just to
see, I'm compiling another kernel with COPTS=-O, instead of -O2.

Ken