From owner-freebsd-current@FreeBSD.ORG Thu Sep 25 22:54:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1B1D16A4B3; Thu, 25 Sep 2003 22:54:25 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEADA43F3F; Thu, 25 Sep 2003 22:54:24 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by localhost.cs.rice.edu (Postfix) with ESMTP id 687534ADEF; Fri, 26 Sep 2003 00:54:24 -0500 (CDT) Received: from cs.rice.edu ([127.0.0.1]) by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27496-04; Fri, 26 Sep 2003 00:54:23 -0500 (CDT) Received: from noel.cs.rice.edu (noel.cs.rice.edu [128.42.1.136]) by cs.rice.edu (Postfix) with ESMTP id E6EC94ADE6; Fri, 26 Sep 2003 00:54:22 -0500 (CDT) Received: (from alc@localhost) by noel.cs.rice.edu (8.9.0/8.9.0) id AAA25380; Fri, 26 Sep 2003 00:54:22 -0500 (CDT) Date: Fri, 26 Sep 2003 00:54:22 -0500 From: Alan Cox To: Robert Watson Message-ID: <20030926055422.GB25202@noel.cs.rice.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030314-p2 at cs.rice.edu cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic on yesterday's -CURRENT: linux emulation and vm (lockmgr: locking against myself) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 26 Sep 2003 05:54:26 -0000 On Thu, Sep 25, 2003 at 11:15:57AM -0400, Robert Watson wrote: > ... > #6 0xc049f355 in vm_fault (map=0xc6fc1700, vaddr=0, fault_type=1 '\001', > fault_flags=0) at /usr/src/sys/vm/vm_fault.c:219 > #7 0xc04eddd9 in trap_pfault (frame=0xdd699b18, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:709 > #8 0xc04eda50 in trap (frame= > {tf_fs = -1070333928, tf_es = -1067384816, tf_ds = 16, tf_edi = 0, > tf_esi = -1068054086, tf_ebp = -580281484, tf_isp = -580281532, tf_ebx = > 441, tf_edx = -968258896, tf_ecx = 0, tf_eax = -968258896, tf_trapno = 12, > tf_err = 0, tf_eip = -1070325008, tf_cs = 8, tf_eflags = 66178, tf_esp = > 0, tf_ss = -1068146900}) > at /usr/src/sys/i386/i386/trap.c:418 > #9 0xc04dd9e8 in calltrap () at {standard input}:102 > #10 0xc04adbde in vm_page_sleep_if_busy (m=0x1b9, also_m_busy=1, msg=0x0) > at /usr/src/sys/vm/vm_page.c:441 > #11 0xc04abcfb in vm_object_split (entry=0xc6eea8ac) > at /usr/src/sys/vm/vm_object.c:1226 > ... Based upon the above information, it looks like vm_object_split() followed a bogus vm page pointer. This is in frequently executed code. So, I would hypothesize a race condition or transient hardware error is responsible. When my recent amd64 and i386 pmap changes are replicated on all platforms that will enable me to introduce additional assertions on the vm object locking. That may reveal some unsynchronized vm object accesses that could lead to the above problem. Alan