Subject: Re: 19990101 kernel panics
To: Anders Magnusson <ragge@ludd.luth.se>
From: Tom Ivar Helbekkmo <tih@nhh.no>
List: port-vax
Date: 02/01/1999 08:50:36
Anders Magnusson <ragge@ludd.luth.se> writes:

> There are a lots of changes, and I still have a bunch that I haven't 
> had time to check in yet. All of this will (I hope) help to get the
> whole vax port both more stable and more easy to maintain.

A couple of things I've found while compiling the January 23rd source
tarballs using the December 1st snapshot (it's not finished yet, but
getting there) (also, I haven't checked what may have been done about
these problems since 1999-01-23):

There are occurrences of "ifdef UVM" in a couple of the header files
under /usr/include/machine, which means that building libc fails.  At
least /usr/src/lib/libc/gen/compat-43/gethostid.c includes
<sys/sysctl.h>, which causes <machine/vmparam.h> to be included, and
that needs UVM defined.  I don't know what's the right way to fix it,
so I just quickly removed the #ifdef/#endif lines here.  :-)

Bad things have happened in /usr/src/lib/libc/arch/vax/ lately.  There
are new source files for [hn]ton[ls] in .../net/, and there are typos
there that cause duplicate definitions -- I'm typing this from memory,
so I don't recall whether both versions define the ...s or the ...l
variants, but it's one or the other.  Easily fixed.  In .../gen/, the
source files __setjmp14.S and __sigsetjmp14.S are no longer being
used, since those names were removed from Makefile.inc.  This caused
things to fail immediately upon installing the new libc.so.12.??.  So
far I've just moved it out of the way, but I'm going to rebuild with
those modules included this afternoon.

That brings me to the big problem: things are certainly much better
than they were until recently, and my KA650 no longer crashes, but
it's obvious that not everything is OK.  The 'make <whatever>' in
/usr/src/lib/libc grows very large, of course, since 'make' is a hog
of fantastic proportions, and this causes weird problems.  Sometimes
it just complains about free() being called with pointers above memtop
(a hexadecimal order of magnitude above, from the debug output),
sometimes it dumps core, and typically makes the parent 'make' do the
same, or even the shell I called 'make' from, which makes me suspect
that really bad things are happening, and occasionally it just gets
hung, causing "scheduler: no room for pid <pid>, <process>, free 1"
messages to appear on the console.  I haven't found any way out of
this hang other than to reset the machine.  Anyway, I'm reserving
judgement on the whole thing until you've got those other fixes you
mentioned committed, and I've got my system up to -current again.

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"