From owner-freebsd-stable@FreeBSD.ORG Sat Jul 4 18:30:30 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86AAD1065673 for ; Sat, 4 Jul 2009 18:30:30 +0000 (UTC) (envelope-from vwe@freebsd.org) Received: from Mail.elbekies.net (mail.elbekies.net [217.6.211.146]) by mx1.freebsd.org (Postfix) with ESMTP id 40D308FC18 for ; Sat, 4 Jul 2009 18:30:30 +0000 (UTC) (envelope-from vwe@freebsd.org) Received: from mail.vtec.ipme.de (Q7c5f.q.ppp-pool.de [89.53.124.95]) by Mail.elbekies.net (Postfix) with ESMTPA id 8E7756784D for ; Fri, 3 Jul 2009 21:56:48 +0200 (CEST) Received: from [192.168.16.4] (dardanos.sz.vwsoft.com [192.168.16.4]) by mail.vtec.ipme.de (Postfix) with ESMTP id BDFA534270; Fri, 3 Jul 2009 21:55:40 +0200 (CEST) Message-ID: <4A4E6273.8060905@freebsd.org> Date: Fri, 03 Jul 2009 21:56:35 +0200 From: vwe@freebsd.org User-Agent: Thunderbird 2.0.0.21 (X11/20090417) MIME-Version: 1.0 To: Ian J Hart References: <20090703100627.197838cphjnil82s@10.248.192.16> In-Reply-To: <20090703100627.197838cphjnil82s@10.248.192.16> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MailScanner-ID: BDFA534270.70BE5 X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: vwe@freebsd.org MailScanner-NULL-Check: 1247255750.35929@Bo4ZOWiU+c6RPrwNJAXnRw Cc: freebsd-stable@freebsd.org Subject: Re: trap 12 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 18:30:30 -0000 On 12/23/-58 20:59, Ian J Hart wrote: > Is this likely to be hardware? Details will > follow if not. > > [copied from a screen dump] > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff807c6c12 > stack pointer = 0x10:0xffffffff510e7890 > frame pointer = 0x10:0xffffff00054a6c90 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1 def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 75372 (printf) > trap number = 12 > panic: page fault > cpuid = 1 > uptime: 8m2s > Cannot dump. No dump device defined. > > Ian, it doesn't look like it's hardware. The message basically means, some code in the kernel was trying to use a NULL pointer (which is by definition a bad pointer) and tried to do something with it. Do you experience that message often? Can you reproduce it easily? To tell you more, we need a backtrace and I'm wondering if you can manage to get the kernel dump being written and have us getting the stack backtrace and more debugging information. If, by any chance, you're using a recent 7.x system, you may want to enable textdump(4) (AFAIR introduced before 7.1, also look at ddb(8)). For setting up your system for kernel crashdumps, please have a look at the handbook and savecore(8). For getting infos out of a kernel crashdump, please check the developers handbook. Please try to get us some debug information and we can then most likely suggest something. HTH Volker