From owner-freebsd-geom@FreeBSD.ORG Thu May 20 12:28:55 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA16C16A4CE; Thu, 20 May 2004 12:28:55 -0700 (PDT) Received: from mail.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14CE543D48; Thu, 20 May 2004 12:28:55 -0700 (PDT) (envelope-from le@FreeBSD.org) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) by mail.univie.ac.at (8.12.10/8.12.10) with ESMTP id i4KJShhS392794; Thu, 20 May 2004 21:28:46 +0200 Date: Thu, 20 May 2004 21:28:46 +0200 (CEST) From: Lukas Ertl To: Pawel Jakub Dawidek In-Reply-To: <20040519161957.GA845@darkness.comp.waw.pl> Message-ID: <20040520212020.Q643@korben> References: <20040519165626.W4275@pcle2.cc.univie.ac.at> <20040519161957.GA845@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: mx7.univie.ac.at 4248; Body=3 Fuz1=3 Fuz2=3 cc: geom@FreeBSD.org cc: Poul-Henning Kamp Subject: Re: Unloading GEOM classes X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2004 19:28:55 -0000 On Wed, 19 May 2004, Pawel Jakub Dawidek wrote: > Here is the patch: > > http://people.freebsd.org/~pjd/patches/g_unload_class.patch > > UNTESTED. Lukas, could you try it and see if it fix your problem. > The whole trick could a g_waitidle() after calling destroy_geom method. Thanks Pawel, but unfortunately, it didn't work out. I subclass the geom_slice class and end up in a panic in g_slice_spoiled() - the geom's consumers have already been destroyed, but the providers have not (if I check for a NULL cp in g_slice_spoiled I end up in an infinite loop, since the geom isn't "empty"). I'm not sure how g_waitidle() can help here, since I don't see where g_pending_events is incremented/decremented in that path. The last relevant thing I see in the g_topology trace is the call to g_orphan_provider(). I haven't found out yet why g_orphan_register isn't called, which would solve the problem, I guess. cheers, le -- Lukas Ertl http://mailbox.univie.ac.at/~le/ le@FreeBSD.org http://people.freebsd.org/~le/