From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 00:00:06 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 420A416A4BF; Mon, 1 Sep 2003 00:00:06 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C1043FEC; Mon, 1 Sep 2003 00:00:05 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.9/8.12.5) with ESMTP id h81704YU061461; Mon, 1 Sep 2003 01:00:04 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.9/8.12.5/Submit) id h816xxQN061450; Mon, 1 Sep 2003 00:59:59 -0600 (MDT) (envelope-from ken) Date: Mon, 1 Sep 2003 00:59:58 -0600 From: "Kenneth D. Merry" To: Pawel Jakub Dawidek Message-ID: <20030901065958.GA61417@panzer.kdm.org> References: <20030830040357.GA42770@panzer.kdm.org> <20030901001345.GE47959@garage.freebsd.pl> <20030901002318.GF47959@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030901002318.GF47959@garage.freebsd.pl> User-Agent: Mutt/1.4.1i cc: current@FreeBSD.org cc: phk@FreeBSD.org Subject: Re: need some debugging help 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, 01 Sep 2003 07:00:06 -0000 On Mon, Sep 01, 2003 at 02:23:18 +0200, Pawel Jakub Dawidek wrote: > On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote: > +> I was getting same panics while I was working on GEOM Gate. > +> After many hours of debugging I've tracked this down - I've initialized > +> a mutex, but I haven't destroy it. > +> > +> As I susspect you're loading cd(4) as kld module? > > No, you don't need to load it as kld module, because you initiate > this mutex on every function call (and mutex is locally allocated to), > so try to put mtx_destroy() on the end of this function, this should help. > (I hope there is no problem with calling msleep(9) with mutex from stack) Well, keep in mind that this function, taskqueue_kthread(), is only called once, when the kthread is forked off. It then runs in an infinite loop forever. So far it doesn't seem like there's any problem with calling msleep() with a mutex allocated on the stack. The problem I was having turned out to be that I forgot to deference periph->softc in dasysctlinit(). Ken -- Kenneth Merry ken@kdm.org