From owner-freebsd-current@FreeBSD.ORG Wed Jul 28 04:27:33 2004 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 0DE5516A4D1 for ; Wed, 28 Jul 2004 04:27:33 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFFF343D39 for ; Wed, 28 Jul 2004 04:27:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 32160 invoked from network); 28 Jul 2004 04:27:32 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 28 Jul 2004 04:27:31 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i6S4QMKn076150; Wed, 28 Jul 2004 00:27:22 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Robert Watson Date: Tue, 27 Jul 2004 23:18:46 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407272318.46256.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: bzeeb+freebsd+lor@zabbadoz.net cc: alc@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033 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: Wed, 28 Jul 2004 04:27:33 -0000 On Tuesday 27 July 2004 06:51 pm, Robert Watson wrote: > On Wed, 28 Jul 2004, Willem Jan Withagen wrote: > > Running on amd64: > > > > > > And right followed by.... > > > > panic: lock (sleep mutex) Giant not locked @ > > /home2/src/sys/kern/vfs_syscalls.c: 959 > > cpuid = 0; > > KDB: stack backtrace: > > kdb_backtrace() at kdb_backtrace+0x34 > > panic() at panic+0x1d2 > > witness_unlock() at witness_unlock+0xdd > > _mtx_unlock_flags() at _mtx_unlock_flags+0x68 > > kern_open() at kern_open+0x128 > > open() at open+0x18 > > syscall() at syscall+0x330 > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (5, FreeBSD ELF64, open), rip = 0x76d75c, rsp = > > 0x7fffffffe088, rbp = 0x7fffffffe0c0 --- > > KDB: enter: panic > > [thread 100316] > > Stopped at kdb_enter+0x2e: nop > > I've seen several reports of "mysterious" panics where Giant isn't held on > return from namei() or other points following a name lookup. Kris > Kenneway reported this on the package build cluster, for example. I'm > wondering if something handling a page fault hit by namei() during a > string copy in from user space if resulting in Giant not being held where > it should be. In Kris's case, we tried pushing around GIANT_REQUIRED some > because I thought maybe the caller wasn't holding Giant when it should, > but that turned out not to be it. So maybe we have some sort of > preemption/VM/locking issue? The preemption case is very easy to test, just turn it off in machine/param.h and see if it goes away. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org