It looks like both the GENERICBT and GENERICAHA kernels have slip
interfaces configured into them, but no com ports?!  Is this an
accident?  I'm trying to currentize my system from the May 1 sources,
and it's becoming a real pain in the ass, since the source tarballs
from this past weekend won't build a kernel (lots of symbols like
P_BACK are referenced in genassym.c, but are defined nowhere that I
can find).

I can't build a new kernel, and the supplied one in the binary dist
has no serial ports.  And my old (May 1st) kernel hangs whenever I try
to push slip or ppp thru it too hard.  And "term" sucks rocks through
a straw (it dies with even moderate traffic [114 does; 118 won't let
me run sup to a priv'd port anymore]).  So, I have no way to sup.

So, can someone look at the GENERIC kernels and put a serial port or
two back in them?  And, hopefully the source tarballs this weekend
will get made without any problems, and maybe I'll be able to build a
kernel with them.  (I already unpacked all the userland binaries.)

				--Michael

P.S. Current (July 12) fsck also freaked out on my SCSI /usr
partition, which had been working fine on the May 1 system, after it
had been working under the July 12 kernel fine for a few hours and I
rebooted.  It complained about a corrupted directory, but only gave
the name as "DIR=?" (it also complained about lost+found being
corrupted).  Then, after complaining about these two dirs, each time
it promptly proceeded to get a segmentation violation.  I rmdir'd the
lost+found dir, which made it happy, but I couldn't even tell what the
other dir was that it was talking about.  And every time it hit that
dir it died with a segv.  I was only able to get that drive to pass
fsck clean by fsck'ing it a couple times under my alternate IDE boot
drive running the May 1 kernel and binaries (including fsck).  The
older fsck called that "DIR=".  It seems the 4.4 version of fsck has a
null pointer dereferenced somewhere if it gets strange dir entries,
that didn't happen under the older fsck.  Sorry I can't provide any
more detailed debugging info since the machine wasn't exactly in a
stable state at the time.  Is this a known problem, or is my machine
just screwey?

-----------------------------------------------------------------------------
 Michael L. VanLoon                 Iowa State University Computation Center
    michaelv@iastate.edu                    Project Vincent Systems Staff
  Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc.
-----------------------------------------------------------------------------



------------------------------------------------------------------------------