Date: Fri, 23 Jun 2006 16:28:49 +0100 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: David Wolfskill <david@catwhisker.org> Cc: stable@freebsd.org Subject: Re: Help? 6.1-S: Fatal trap 12: page fault while in kernel mode Message-ID: <1151076529.62769.17.camel@buffy.york.ac.uk> In-Reply-To: <20060615232240.GX32476@bunrab.catwhisker.org> References: <20060615232240.GX32476@bunrab.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2006-06-15 at 16:22 -0700, David Wolfskill wrote:
> I had one of these a couple of weeks ago or so; I had been distracted by
> some more urgent matters that came up (the panic was on a machine under
> test; the more urgent matters were little things like needing to deploy
> a handful of resolvers on our network because existing ones were running
> on systems that had provided evidence of being prone to imminent
> failure).
>
> Anyway: I updated the 2 boxen under test to 6.1-STABLE as of this
> morning, and finally(!) had a chance to re-try the failing operation.
>
> It went "kaboom!" again. :-{ (Well, there's something to be said for
> consistency. :-})
>
> It seems to run OK (albeit slowly) for a couple of minutes; then the
> serial console reports:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 06
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0x0
> stack pointer = 0x28:0xf09b3b98
> frame pointer = 0x28:0xf09b3bcc
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 23782 (ecelerity)
> [thread pid 23782 tid 100120 ]
> Stopped at 0: *** error reading from address 0 ***
> db> trace
> Tracing pid 23782 tid 100120 td 0xcc445180
> db>
OK, seeing as nobody has offered any advice, I'll have a go.
Have you got a debug kernel? If so, get a kernel dump. Load it into
kgdb. Chances are "bt" won't work as the instruction pointer is zero,
so instead you need to display the stack directly:
(kgdb) x/80xw 0xf09b3b98
Look for any addresses in the 0xc0xxxxxx range - these will probably be
pointers to kernel functions. Drop out of kgdb, and try to find out
which functions these belong to:
addr2line 0xc0639bd6 -e kernel.debug
/usr/src/sys/kern/tty.c:1653
You can build up a backtrace and knowledge of atguments given to
functions this way.
Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1151076529.62769.17.camel>