Subject: Re: Heads up: shared arm include files
To: Chris Gilbert <chris@buzzbee.freeserve.co.uk>
From: Ben Harris <bjh21@netbsd.org>
List: port-arm32
Date: 01/12/2001 20:09:14
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>).
> trying uvmhist_dump causes a translation fault (section).
uvmhist_dump() takes the address of a history (eg ubchist, or pmaphist on
arm26) as an argument. If you don't give it one, a translation fault is a
likely outcome.
--
Ben Harris <bjh21@netbsd.org>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>