From owner-freebsd-current@FreeBSD.ORG Mon Jan 24 13:46:00 2005 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 D880F16A4CE for ; Mon, 24 Jan 2005 13:46:00 +0000 (GMT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C8A143D4C for ; Mon, 24 Jan 2005 13:46:00 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 8FB8326443B; Mon, 24 Jan 2005 14:45:58 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id DD6B3407C; Mon, 24 Jan 2005 14:45:46 +0100 (CET) Date: Mon, 24 Jan 2005 14:45:46 +0100 From: Jeremie Le Hen To: Poul-Henning Kamp Message-ID: <20050124134546.GB59685@obiwan.tataz.chchile.org> References: <20050123190141.GQ36660@obiwan.tataz.chchile.org> <54109.1106552312@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54109.1106552312@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: freebsd-current@FreeBSD.org cc: Jeremie Le Hen Subject: Re: cvs commit: src/sys/dev/md md.c 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: Mon, 24 Jan 2005 13:46:01 -0000 > Can you add some more yourself ? We need to find out where Giant > is lost, it is picked up here: > > case MD_VNODE: > mtx_lock(&Giant); > hasgiant = 1; > break; > > And only dropped again when we exit. > > Somehow it gets lost on your machine and there is nothing but for us > to find out where. > > Can you try if you can reproduce it with WITNESS enabled ? First, I want to tell that I have triggered the panic even with softupdates disabled. When I first tried it, I thought the panic was occuring immediately on creation of the first md(4) device, therefore when I succeeded in creating /dev/md0 with a non-softupdates filesystem, I believed this was related. In fact, I think now it's clearly a race condition since the panic is not reproducible in a deterministic way. Sometimes it occurs on the first creation of a md(4) device, sometimes I have to create up to 4 devices to get it triggered. While talking about WITNESS, I checked my kernel config and remembered that FULL_PREEMPTION is on. The panic disappeared when I turned off the latter : I managed to create up to about 16 md(4) devices. I know this should not be enabled for users, but I'm interested in "exposing race conditions" as said in the comment. I think you don't really have time to fix this kind of bugs caused by FULL_PREEMPTION so I'll try myself. I'm sorry for wasting your time. FYI, here is my kernel configuration: %%% options PREEMPTION options FULL_PREEMPTION options MUTEX_DEBUG options KDB options DDB options INVARIANT_SUPPORT options INVARIANTS options DIAGNOSTIC options WITNESS options WITNESS_KDB options SCHED_ULE %%% Following some advices from a friend of mine, I'm going to give a try to the KTR tracing facility. First I wanted to set a watchpoint on Giant, but I've been told that this feature is not very efficient and furthermore I'm dreading that Giant might be used many times a second. Advices and help are of course welcome. -- Jeremie Le Hen jeremie@le-hen.org