From owner-freebsd-hardware@FreeBSD.ORG Wed Apr 11 14:32:10 2007 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E22016A405 for ; Wed, 11 Apr 2007 14:32:10 +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 F0CA513C448 for ; Wed, 11 Apr 2007 14:32:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3BEW6M3075077; Wed, 11 Apr 2007 10:32:06 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Wed, 11 Apr 2007 10:13:28 -0400 User-Agent: KMail/1.9.4 References: <4614F070.2000302@fx-services.com> In-Reply-To: <4614F070.2000302@fx-services.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704111013.28425.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Wed, 11 Apr 2007 10:32:07 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3067/Wed Apr 11 06:21:12 2007 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: Robin Vley Subject: Re: SMP crashes / reboots 5.4 with CPanel X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2007 14:32:10 -0000 On Thursday 05 April 2007 08:49, Robin Vley wrote: > Hi! > > I posted this to the FBSD-Questions mailinglist, because I'm completely > not sure if this is hardware or software. Last time I got some good > pointers there, but since I'm 100% in the dark where this is coming > from, I crosspost it here. > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 01 > fault virtual address = 0x98 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc06b7f1e > stack pointer = 0x28:0xece5f730 > frame pointer = 0x28:0xece5f774 > 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 = 69885 (dcpumon) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 2d22h1m13s > Dumping 2047 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 2047MB (523904 pages) 2031 2015 1999 1983 1967 1951 1935 1919 > 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 > 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 > 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 > 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 > 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:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc063efca in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xc063f396 in panic (fmt=0xc0870bd4 "%s") at > /usr/src/sys/kern/kern_shutdown.c:555 > #3 0xc082e16c in trap_fatal (frame=0xece5f6f0, eva=0) at > /usr/src/sys/i386/i386/trap.c:831 > #4 0xc082de52 in trap_pfault (frame=0xece5f6f0, usermode=0, eva=152) at > /usr/src/sys/i386/i386/trap.c:742 > #5 0xc082da02 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 4, tf_esi = 0, tf_ebp > = -320473228, tf_isp = -320473316, tf_ebx = 4098, tf_edx = -1002850048, > tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2, tf_eip = > -1066696930, tf_cs = 32, tf_eflags = 66118, tf_esp = -320473100, tf_ss = > 1017}) > at /usr/src/sys/i386/i386/trap.c:432 > #6 0xc0817d0a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc06b7f1e in vn_lock (vp=0x0, flags=4098, td=0xc439b900) at > atomic.h:149 > #8 0xc05eee46 in procfs_doprocfile (td=0xc439b900, p=0xc9068830, > pn=0xc35f3900, sb=0x4, uio=0x0) at /usr/src/sys/fs/procfs/procfs.c:73 > #9 0xc05f3f5b in pfs_readlink (va=0x4) at pcpu.h:162 So a bug in procfs. I would try 6.2. I do know of one procfs/vnode locking bug fixed in 6.x after 6.2, btw. -- John Baldwin