Subject: Re: mem_access_fault panics on netbsd/sparc
To: Paul Kranenburg <pk@cs.few.eur.nl>
From: David Brownlee <D.K.Brownlee@city.ac.uk>
List: port-sparc
Date: 10/16/1995 23:44:15
	Thanks for the explanation - I think I understood it the second
	read through (though it may have been the third - but thats my
	problem :)

	Unfortunately my ss2 server is going to pieces so fast I'm still
	pulling scrapnel our of the walls :( - I think I noticed a similar
	problem ealier this week when I put 48Mb in a (lighter loaded)
	ELC... Has anyone else had problems in sun4c machines with large
	(ish) quantities of memory (>32Mb)?

		David/abs

 D.K.Brownlee@city.ac.uk (MIME) +44 171 477 8186  {post,host}master  (abs)
I've been too drunk to love             ||  I've been too drunk to remember
Too drunk to care                       ||     The Hell of the night before
I've looked like death, felt like Hell  ||  I've been drinking myself blind
Been the worse for wear                 ||   And still I'll drink some more

On Mon, 16 Oct 1995, Paul Kranenburg wrote:

> > 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
>