From owner-freebsd-hackers  Mon Apr 28 11:06:14 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA28425
          for hackers-outgoing; Mon, 28 Apr 1997 11:06:14 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28414
          for <freebsd-hackers@freebsd.org>; Mon, 28 Apr 1997 11:06:10 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id LAA15768;
	Mon, 28 Apr 1997 11:05:16 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd015764; Mon Apr 28 18:05:12 1997
Message-ID: <3364E6BB.41C67EA6@whistle.com>
Date: Mon, 28 Apr 1997 11:04:43 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Simon Shapiro <Shimon@i-Connect.Net>
CC: freebsd-hackers@freebsd.org
Subject: Re: A Desparate Plea for Help...
References: <XFMail.970427164721.Shimon@i-Connect.Net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Simon Shapiro wrote:
> 
> hi Y'all,
>
> 
> The last and most troubling problem is a complete crash/freeze when running
> certain X11 applications;  At ONE point, we managed to observe a panic that
> went something like:
> 
> Fata trap 12 page fault at 0xf71e0014
> 
> _spec_open+0x6e
> _vm_open
> _open
> _syscall
> _Xsyscall
> 
> There was a mention of bash in this panic.

The best thing for you to do with this
is to compile the gernet
using -g
do this by using 
config -g
do: (on the compile machine)
make
cp kernel kernel.debug
strip -d kernel

also:
cat >.gdbinit <<DONE
set remotebaud 9600
file kernel.debug
target remote  /dev/cuaa1
DONE


compile the options DDB and set the default 
debugger to be gdb by booting with -g

then if you get a crash,
make sure that /dev/cuaa1 (com2) on your source machine is
connected to com1 on the victim machine 
and type 
cd /sys/compile/<MYKENREL>
gdb

this (due to the .gdbinit) will fire up gdb and allow you to walk up and
down the 
stack trace of the crashed kernel.

even if the screen is stuck in X11.

there are some problems I've seen.

1/ the newest gdb versions are not as good at doing this as some of the
older ones.
and sometimes get confused.
2/ you must remember to make sure the system has sert gdb to be the
kernel debugger.
(there may be a compile time option for this.. I forget)
3/ some uarts don't like this if com1 is already being used for
something..
(move your mouse to com2)



julian