From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 21 17:29:41 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E3E16A630 for ; Mon, 21 Aug 2006 17:29:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47CAB43D79 for ; Mon, 21 Aug 2006 17:29:37 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k7LHTCGs011401; Mon, 21 Aug 2006 13:29:22 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Mon, 21 Aug 2006 12:49:06 -0400 User-Agent: KMail/1.9.1 References: <200608192359.36462.pieter@degoeje.nl> In-Reply-To: <200608192359.36462.pieter@degoeje.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608211249.07018.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 21 Aug 2006 13:29:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1702/Mon Aug 21 11:23:21 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: Panic on 6.1REL using linux compat X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 17:29:41 -0000 On Saturday 19 August 2006 17:59, Pieter de Goeje wrote: > The box in question is a dual core athlon64, running 6.1-RELEASE-p3 amd64 with > SMP enabled. The box has been panicing every month or so, and i've obtained a > crashdump the last time. The primary use for the box is hosting Half-Life > Dedicated Servers, using linux compatibility. One of them was the current > process seen in the panic below. > > Backtrace: > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xffffffff8023d923 > stack pointer = 0x10:0xffffffffa79c9620 > frame pointer = 0x10:0x4 > 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 = 74823 (hlds_amd) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 14d14h36m48s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 1023MB (261808 pages) 1007 991 975 959 943 927 911 895 879 863 847 > 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 > 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 > 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:172 > 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:172 > #1 0x8888888888888889 in ?? () > #2 0xffffffff801f97d7 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:402 > #3 0xffffffff801f9e71 in panic (fmt=0xffffff000a44abe0 "") > at /usr/src/sys/kern/kern_shutdown.c:558 > #4 0xffffffff803350ff in trap_fatal (frame=0xffffff000a44abe0, > eva=18446742974534823936) at /usr/src/sys/amd64/amd64/trap.c:660 > #5 0xffffffff8033541f in trap_pfault (frame=0xffffffffa79c9570, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:573 > #6 0xffffffff803356d3 in trap (frame= > {tf_rdi = 72, tf_rsi = 0, tf_rdx = 72, tf_rcx = 0, tf_r8 > = -1098734541056, tf_r9 = 50, tf_rax = 144, tf_rbx = -1098734541056, tf_rbp = > 4, tf_r10 = -1098734541056, tf_r11 = -2144558112, tf_r12 = -1098734541056, > tf_r13 = -1099503775744, tf_r14 = 0, tf_r15 = 1, tf_trapno = 12, tf_addr = > 72, tf_flags = -2144884788, tf_err = 0, tf_rip = -2145134301, tf_cs = 8, > tf_rflags = 66054, tf_rsp = -1482910152, tf_ss = 0}) > at /usr/src/sys/amd64/amd64/trap.c:352 > #7 0xffffffff80321acb in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:168 > #8 0xffffffff8023d923 in m_length (m0=0x48, last=0x0) > at /usr/src/sys/kern/uipc_mbuf.c:1173 > #9 0xffffffff8023d94b in m_fixhdr (m0=0xffffff002e516700) > at /usr/src/sys/kern/uipc_mbuf.c:1161 This doesn't make any sense.. m0 is passed directly to m_length, it's value shouldn't change. You either have a random memory corruption bug or you have faulty hardware. -- John Baldwin