From owner-freebsd-current@FreeBSD.ORG Fri Jul 27 00:50:21 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34F8E16A41A for ; Fri, 27 Jul 2007 00:50:21 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (unknown [IPv6:2001:5a8:4:2140:21b:fcff:fe24:feef]) by mx1.freebsd.org (Postfix) with ESMTP id F406113C4CC for ; Fri, 27 Jul 2007 00:50:20 +0000 (UTC) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.14.1/8.14.1) with ESMTP id l6R0oKxI014498; Thu, 26 Jul 2007 17:50:20 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.14.1/8.14.1/Submit) id l6R0oKx5014497; Thu, 26 Jul 2007 17:50:20 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: Milos Vyletel Date: Thu, 26 Jul 2007 17:50:19 -0700 User-Agent: KMail/1.9.6 References: <20070721174631.S561@10.0.0.1> <20070722114846.GA97996@rulez.sk> <20070722121631.GA8336@rulez.sk> In-Reply-To: <20070722121631.GA8336@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707261750.19994.peter@wemm.org> Cc: current@freebsd.org Subject: Re: ULE status, invalid load, buildkernel times. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2007 00:50:21 -0000 On Sunday 22 July 2007, Milos Vyletel wrote: > On Sun, Jul 22, 2007 at 01:48:46PM +0200, Milos Vyletel wrote: [...] > > No problem, > > > > I've extracted it and made a patch. If someone is intrested, it's > > on > > > > http://rulez.sk/~mv/cpu.patch > > Well, i've just updated my kernel and it paniced right after > identifying cpu. > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2205.01-MHz > K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f32 Stepping = 2 > > Features=0x178bfbffPGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > usable memory = 3211776000 (3062 MB) > avail memory = 3105628160 (2961 MB) > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x310 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff8033953c > stack pointer = 0x10:0xffffffff80855c70 > frame pointer = 0x10:0xffffffff80855c80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 0 () > > this is output from from dmesg. > > Thanks for suggestions. > Milos Unfortunately this isn't much help. What would be useful would be to get a backtrace. If you're not running GENERIC, a copy of your kernel config would be useful. Any other patches? To get a backtrace, add these to your kernel config: options KDB options DDB #options KDB_TRACE #options KDB_UNATTENDED The last two options would help automate it for you, but beware. KDB_TRACE shows a trace during the panic. The problem is that ddb is activated before the machine actually panics, so you'd be dropped into ddb before the trace got printed. Give a 'trace' command at the 'db>' prompt. KDB_UNATTENDED prevents it dropping into ddb, and simply prints the trace and gets on with the panic. It might be a bit harder to get a record of what happened. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5