From owner-freebsd-bugs  Sun Dec  3 14:00:09 1995
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id OAA27122
          for bugs-outgoing; Sun, 3 Dec 1995 14:00:09 -0800
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id OAA27061
          ; Sun, 3 Dec 1995 14:00:05 -0800
Date: Sun, 3 Dec 1995 14:00:05 -0800
Message-Id: <199512032200.OAA27061@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: David Greenman <davidg@Root.COM>
Subject: Re: kern/863: panic on kernel page fault, NULL curproc 
Reply-To: David Greenman <davidg@Root.COM>
Sender: owner-bugs@FreeBSD.ORG
Precedence: bulk

The following reply was made to PR kern/863; it has been noted by GNATS.

From: David Greenman <davidg@Root.COM>
To: hsu@clinet.fi
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/863: panic on kernel page fault, NULL curproc 
Date: Sun, 03 Dec 1995 13:52:18 -0800

 >Current directory is /var/crash/
 >Reading symbol data from /var/crash/kernel.37...done.
 >IdlePTD 26d000
 >panic: m_copydata
 
 >#5  0xf01c5b3d in exception:calltrap ()
 >(kgdb) down
 
    With all the "up"s and "down"s this is all quite difficult to read. What
 I'd really prefer is just a straight "bt" backtrace.
 
 -DG
 
 >	Don't know yet; this could be related to my previous report
 >shipped a couple of minutes ago (access to freed mbuf?).
 
    The above panic is m_copydata...which is the same one in your previous
 report. What you're seeing is the system trying to sync out filesystems
 buffers after the crash and then stumbling over the fact that there is no
 process context at this point. It's a bug that it doesn't handle this
 condition properly.
 
 -DG