On Wed Dec 31 2003 at 20:12:12 +0900, Christopher SEKIYA wrote:
> > I traced it dying inside the uvm_pageboot_alloc() in mach_init()
> > (allocating USPACE).
> 
> maybe fallout from the switch to memory pools committed by pk yesterday?  a
> quick before-and-after diff reveals interesting changes to the uvm allocate
> code in mach_init().

Yes and no; the bug has always existed I believe, the changes only make
it actually get triggered I think.

The only relevant changes are removal of allocsys() (which only
calculated nbufs for pmap_bootstrap()) and the slight changes in
pmap_bootstrap() (which seem ok, and even if they weren't they shouldn't
cause trouble in pmap_steal_page()). We never get as far as
cpu_startup(), so the changes in that are irrelevant.

I think this is getting triggered because the allocation pattern has
changed.

Also, the addresses handled inside pmap_steal_memory() seem to be valid
ones, and this is not the first call to uvm_pageboot_alloc() - the
earlier ones (in pmap_bootstrap()) succeed. pk's commit didn't touch the
uvm_page_physload() path, which makes me think the bug has always
existed.

Oh, and this happens to me with a very small kernel:
starjumper:~# ls -lap /boot/netbsd
-rwxr-xr-x    1 root     root      1756878 Dec 31 12:40 /boot/netbsd

GENERIC32_IP2x boots just fine (probably because it's so much larger and
causes different memory usage patters).

-- 
Ilpo Ruotsalainen - <lonewolf@iki.fi> - http://www.iki.fi/lonewolf/