On Sat, 25 Aug 2001, matthew green wrote:

>
>            - The fact that -current is much better than 1.5.x on
>              sparc64 is not news to most on this list, but we really
>              ought to mention this on the webpage. Had I just stuck
>              with 1.5.1 on the box I would never have considered
>              putting it to real use. -current changed that.
>
> can you handle this side of things?  :-)
>
	I'll try to come up with something :)

>            - Found the odd compiler codegen and LP64_LE issue in pkgsrc
>              but its happily compiled up and run a bunch of applications
>              including apache, gimp, ghostscript, xv, perl.
>
> avoiding -O2 can often remove these problems.  others require source
> modifications... also pkgsrc has a bunch of fixes already.  you should
> probably get patches into pkgsrc for any problems you find.
>
	Have been doing so as I go along :)

>            - The only real issue I've hit is that there seems to be
>              a problem compiling C++. A 'hello world' program will
>              fail at runtime with:
>    /usr/lib/libstdc++.so.4: Undefined symbol "" (reloc type = 54, symnum = 18)
>              gcc -v reports 2.95.3. Was this toolchain used to build
>              the snapshot? (ie: groff)
>
> groff doesn't use libstdc++, but this is basically a known issue.  C++
> in general doesn't work on sparc64 though some applications that only
> use a small subset of C++ (like groff) will work just ine.
>
	IS the new toolchain liable to affect this?

>            - Its a 256MB machine but it always seems to have over
>              100MB free, I would have expected the UBC to take care
>              of that?
>
> this is probably because the default number of vnodes is too small.
> my ultra1 with 256MB of ram currently says:
>
> There are 22598 pages for vnode page cache using 180784 kBytes of memory.
>
> but i have:
>
> 	options         NVNODE=15000
>
> in my kernel config, which allows it to use more vnodes and thus to
> cache more ram for files.  (as i understand it, pages in the page
> cache need to have active vnodes.)

	Many thanks - my free memory appears to be usefully caching files
	now :) Is there any reason we do not autosize NVNODE more usefully
	based on the total memory?

-- 
		David/absolute		-- www.netbsd.org: No hype required --