On Tue, 8 Aug 2000, Cliff Neighbors wrote:

> with  some minor tweaking my G4 w/ 2GB SDRAM is now running OK.
> there are a couple issues:

Cool!

> 1. int physmem:
> 
>    the page hash table is auto-sized in pmap_bootstrap()\pmap.c:
> 
> 	#ifdef  HTABENTS
> 		ptab_cnt = HTABENTS;
> 	#else /* HTABENTS */
> 		ptab_cnt = 1024;
> 		while ((HTABSIZE << 7) < ctob(physmem))
> 			ptab_cnt <<= 1;
> 	#endif /* HTABENTS */
> 
>    with >= 2GB RAM, ctob(physmem) as a signed quantity 
>    will evaluate negative right off so ptab_cnt never gets
>    adjusted upwards.  The result is overflow of the (puny)
>    page table during startup before VM is initialized
>    which results in panic("poalloc").
> 
>    three possible fixes:
> 
> 	b. cast the values being compared in the above while loop
> 	   to unsigned.

Either this, or do things differently. Both alpha and i386 work fine w/
2GB or more of ram. There probably is a better way. ;-)

> 	c. re-declare physmem as unsigned (in pmap.c and systm.h).
> 	   one might wonder why, aside from historical oversight,
> 	   physmem would need to be signed.

I think it's for efficiency. physmem holds the number of pages of memory,
so it is good, with 8k pages, out to around 16 Terrabytes of main memory.

>    of course, anywhere else you see something like ctob(physmem)
>    or its equivalent (physmem << PGSHIFT) is worth a look.

Yep. :-)

>    the one other case I found seemed relatively harmless if incorrect,
>    specifically in sbin/sysctl/sysctl.[ch] & sys/kern/kern_sysctl.c:
>    incorrect as there is no currently existing CTLTYPE for 
>    unsigned int (should be pretty straightforward to add); 
>    harmless depending on who/what ever looks at the value reported 
>    by sysctl.
> 
> 2. buffer sizing:
> 
>    the "traditional" method of auto-sizing the I/O buffer pool
>    i.e. 10% of the first 2MB and 5% of the remaining,
>    is broken for large memory systems, for the macppc kernel
>    anyway.  with 2GB RAM, 5% is > 100MB, which can really put
>    a dent in your kernel virtual space, if you had that 
>    much to spare.  for me it was
>  
> 	panic: startup: cannot allocate VM for buffers
>    
>    The obvious workaround there is to manually configure
>    a buffer pool that will fit.  again, that's not a great
>    solution if you want to run the same kernel on a 
>    not-huge memory system, so perhaps a modification on the
>    traditional forumla would be in order, perhaps a cap
>    on how big the pool can be, perhaps modulated by how
>    much kernel virtual space is available?

Sounds like a subject for tech-kern or port-powerpc.

> 3. cpu_startup()\machdep.c calls format_bytes()\kern_subr.c
>    to format up a pretty string to report memory size.
>    format_bytes expects the 3rd arg to be a u_int64_t;
>    so the call in cpu_startup may deserve a type cast on
>    that arg.
> 
> on the whole 2G was not a big deal, and it's to the credit of 
> netbsd and the macppc port in particular that this was
> as painless as it was.  hope the above data helps,
> in case anyone ever wants to run with lots-o-RAM.
> 
> regards,
> 	-cliff-
> 
> ---
> cliff neighbors
> allegro networks, inc.
> cliff@allegronetworks.com
> 408-281-5532
> ---
> 
>