On Fri, 26 May 2000, Mason Loring Bliss wrote:

> Hi, all.
> 
> I took another run at getting my SS10 up to speed today. It's currently
> running 1.4X and is rock solid. Whenever I try a 1.4Y kernel, I start
> seeing all sorts of core dumping.
> 
> Does anyone have any thoughts regarding this? I have core dumps galore,
> but I'm not quite sure how to pick them apart yet.
> 
> PS: This core dumping seems completely orthogonal to:
> 
> * The presence or absence of INET6.
> * The presence or absense of softdep and softdep-enabled filesystems.
> * The presence or absense of update(8) with frequent syncs.
> 
> *Most* of the time, /etc/rc.d/network start in single-user mode will not
> dump core, whereas 100% of the time the same thing during multi-user boot
> *will* dump core. (Specifically, an instance of /bin/sh that ends up
> driving ifconfig, I believe, dumps core, leaving the system without
> networking resources.)
> 
> Since the box mostly exists to track -current and play with new (to me,
> anyway) technology, I feel silly leaving it at 1.4X, so any ideas with
> regard to diagnostics are welcome. So far, the only thing I've thought
> of involves setting it up to netboot, thus isolating the possibility of
> some kind of evil interaction with the disks or SCSI controller. I'll
> try this this weekend.

Why is it dumping core?

I recommend enabling DDB and putting a breakpoint in trapsignal().  You
can get a stacktrace to find out why it's being called.  

If it's coming from one of the mem_access_fault() routines, find out what
the faulting address was and you may learn something useful.

Another thing to do is look for consistency.  Make backtrace the
instructions and verify that the register contents match the memory.  I
really need to put a plug for Chris Drake's _Panic!_ book on the web site
so I don't have to keep doing it through email.

Eduardo Horvath