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

I had no problems building a new kernel from Friday Night.  Drop by
this weekend and I'll give you a tape with everything you want, or a
floppy with your very own CUSTOM kernel on it (bring a config file).

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

I had the same thing happen to my root partition; I thought it was from
the 1522 SCSI controller experiment.  I eventually had to newfs the
root partition and start over from scratch.  I also didn't have an
older fsk to fix the disk with, so I was really stuck.

Other than that, the segfault, etc. sounds precisely like the symptoms
that I was experiencing.  I tried everything else I could think of and
the goofy thing would not clear the bad spot nor complete reliably.


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