> On Fri, 12 Jan 2001, Chris Gilbert wrote:
> 
> > > > Currently I'm having fun chasing a bug with UBC, or probably the pmap/uvm
> > > > stuff, seems that if we've got maxproc above some val between 96 and 104
> > > > (at 104 it actually hangs, doesn't find the root device, above this it
> > > > does fail with UBC_init error) UBC_init fails, note that I'm about to
> > > > chase it with UVMHISTORY and _PRINT (although the PRINT bit makes booting
> > > > really really slow, but at least I've got it narrowed down a bit, anyone
> > > > know of a less painful way to chase this kind of bug?).
> > >
> > > You don't need to turn on history printing -- you can call uvm_hist() or
> > > uvmhist_dump() from DDB.  What's the precise panic message, anyway?
> > 
> > ahh, great.  Panic message is:
> > panic: ubc_init: failed to map ubc_object
> > 
> > call to uvm_hist shows that:
> > uvm_map is called with:
> > map=0xf01b22b8,m *startp=0x0, size=8388608, flags=0x41727
> > 
> > this calls uvm_map_findspace
> > it gets a:
> > <- failed (off end)
> 
> I think that means that the ubc_object is too big, so you haven't got
> enough kernel VM for it.  I ran into this problem on arm32 (which has very
> little VM space) and fixed it by forcing UBC_NWINS to be fairly small.  I
> don't feel this should happen on arm32 since you've got 4GB of address
> space to play with, though the Risc PC port does insist on only having
> 48MB of that available for the kernel's use (KERNEL_VM_SIZE in
> <machine/vmparam.h>).
> 
I wonder if the tiny amount of kernel vm space is the reason why my current 
kernel has fork failures while trying to go multi-user. I wonder why the 
kernel is restricting itself to such a tiny space. On i386 the kernel starts 
at 0xc0000000 which gives much more headroom for buffers and other KVM 
structures. I guess the only thing to do is to start digging at the initarm 
code to rearrange the kernel VM space. I wonder what the boot time 
implications of changing this are?

Mike