From owner-freebsd-questions@FreeBSD.ORG Thu Dec 11 15:42:40 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 535C81065678 for ; Thu, 11 Dec 2008 15:42:40 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D117F8FC16 for ; Thu, 11 Dec 2008 15:42:39 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LAngP-0001eM-KU for freebsd-questions@freebsd.org; Thu, 11 Dec 2008 15:42:33 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Dec 2008 15:42:33 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Dec 2008 15:42:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Ivan Voras Date: Thu, 11 Dec 2008 16:42:28 +0100 Lines: 61 Message-ID: References: <20081211154602.M1327@wojtek.tensor.gdynia.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: <20081211154602.M1327@wojtek.tensor.gdynia.pl> Sender: news Subject: Re: FreeBSD amd64 crash - why? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2008 15:42:40 -0000 Wojciech Puchar wrote: > (kgdb) bt\  > #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff8029cde9 in boot (howto=260) at > ../../../kern/kern_shutdown.c:418 > #3 0xffffffff8029d202 in panic (fmt=0x104
) > at ../../../kern/kern_shutdown.c:574 > #4 0xffffffff804da163 in trap_fatal (frame=0xffffff0001ae06e0, > eva=Variable "eva" is not available. > ) > at ../../../amd64/amd64/trap.c:764 > #5 0xffffffff804da535 in trap_pfault (frame=0xffffffffa53818f0, > usermode=0) > at ../../../amd64/amd64/trap.c:680 > #6 0xffffffff804dae85 in trap (frame=0xffffffffa53818f0) at > ../../../amd64/amd64/trap.c:449 > #7 0xffffffff804c083e in calltrap () at > ../../../amd64/amd64/exception.S:209 > #8 0xffffffffa5381b00 in ?? () > #9 0xffffff0001ae06e0 in ?? () > #10 0xffffffff804cb596 in ipi_bitmap_handler (frame= > {tf_rdi = -2140742176, tf_rsi = -1523049488, tf_rdx = 4104, tf_rcx > = 715684, tf_r8 = -1098907750400, tf_r9 = -2140669600, tf_rax = 7840359, > tf_rbx = -2140742176, tf_rbp = -2140614400, tf_r10 = 4640, tf_r11 = 116, > tf_r12 = 5153376776576, tf_r13 = -1523049728, tf_r14 = 71567949, tf_r15 > = 2, tf_trapno = -1523049712, tf_addr = -1099483445536, tf_flags = > -1099212052096, tf_err = 0, tf_rip = -2145744350, tf_cs = 8, tf_rflags = > 582, tf_rsp = -1523049824, tf_ss = 16}) > at ../../../amd64/amd64/mp_machdep.c:979 > #11 0xffffffff804c1236 in Xipi_intr_bitmap_handler () at apic_vector.S:206 > #12 0xffffffff801a8a22 in acpi_timer_read () at cpufunc.h:239 > #13 0xffffffff801a8a47 in acpi_timer_get_timecount_safe (tc=Variable > "tc" is not available. > ) at ../../../dev/acpica/acpi_timer.c:244 > #14 0xffffffff802a81aa in binuptime (bt=0xffffffffa5381b00) at > ../../../kern/kern_tc.c:167 > #15 0xffffffff802a8230 in bintime (bt=0xffffffffa5381b00) at > ../../../kern/kern_tc.c:217 > #16 0xffffffff802a82b7 in microtime (tvp=0xffffffffa5381b20) at > ../../../kern/kern_tc.c:237 > #17 0xffffffff802adb17 in gettimeofday (td=Variable "td" is not available. > ) at ../../../kern/kern_time.c:430 > #18 0xffffffff804da754 in syscall (frame=0xffffffffa5381c80) at > ../../../amd64/amd64/trap.c:907 > #19 0xffffffff804c0a4b in Xfast_syscall () at > ../../../amd64/amd64/exception.S:330 > #20 0x0000000800d96bdc in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) [root@serwer ~]# exit > The code path in this backtrace is very low-risk, there are not many things that can go wrong in a gettimeofday() call. It's very likely it's a hardware problem (tried memtest86 recently?), but you should post it to current@ to verify. You might want to switch to TSC timecounter if it's available on your hardware (see kern.timecounter.smp_tsc) to avoid the acpi_timer* code path and see if the system still panics.