Subject: Re: no com ports in GENERIC* kernels??
To: Michael L. VanLoon -- Iowa State University <firstname.lastname@example.org>
From: Dave Burgess <email@example.com>
Date: 07/20/1994 18:54:54
> 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.)
> 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.