Date: Fri, 1 Aug 2003 10:59:06 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Kris Kennaway <kris@obsecurity.org> Cc: current@FreeBSD.org Subject: Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000 Message-ID: <16170.32826.78241.478325@grasshopper.cs.duke.edu> In-Reply-To: <20030801131430.GA20056@rot13.obsecurity.org> References: <20030731084859.GB36327@rot13.obsecurity.org> <20030731204842.GA14640@rot13.obsecurity.org> <16170.25724.359310.850644@grasshopper.cs.duke.edu> <20030801131430.GA20056@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway writes:
> On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote:
>
> > The crashdump might actually be useful here. You'd have only the
> > trap() and vm_fault() frames, but at least you'd have information
> > about the state of the vm system.
>
> Two crashdumps coming up! I'll move them onto beast:/j/kris/crash
> together with the kernel.debug.
>
I may have wasted your time. The first one is unusable (lots of ddb
cruft). Damned gdb -k. Grrr.
I don't have read perms on vmcore.{1,2}, so I don't know if they are
helpful.
If you're willing to get your traces via ddb's debug.trace_on_panic
and to set debug.debugger_on_panic=0, then we might get at least a
partial trace. FWIW, I have to do this to get any sort of crashdump
at all on SMP x86. I'm amazed you were able to call doadump from ddb.
When I try that on x86, I just get a continuous stream of panics or
fatal traps.
Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16170.32826.78241.478325>