> note: crowded chunk at 0x1000000
> note: crowded chunk at 0x2fce000
> note: crowded chunk at 0x1000000
> note: crowded chunk at 0x2fce000
> 
> 	(at least the crowded messages are different)
> 	should I take it down to 32/36Mb?
> 	are the crowded messages indicative of bad things to come?

no, it's a left-over from the days I changed the way `pv_table' in pmap.c
is allocated. The "virtual" physical memory array as seen by the VM system
can be much larger than actual physical memory present in the machine (there
are holes which are a function of the memory sockets and the size of the
memory chips you put into them), so the virtual memory range allocated to
`pv_table' (which maps virtual physical pages to actual physical pages)
is in fact not entirely covered by physical memory (which saves pages)
and only has those ranges mapped that correspond to actual physical pages.

Since each `pv_table' entry maps a page, and `pv_table' itself can of course
only be mapped with page granularity, it can happen that two adjacent
chunks of physical memory have some of their corresponding `pv_table' page
description entries on the same page within `pv_table', i.e. those chunks
have a small gap between them.

Sorry to confuse you more..

The moral of this is, of course, that I should have taken that debug
statement out long ago :-)

-pk