From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 09:10:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C06DF16A4CF; Wed, 21 Jul 2004 09:10:55 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 883F843D4C; Wed, 21 Jul 2004 09:10:54 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i6L9ADuu077108; Wed, 21 Jul 2004 10:10:13 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Wed, 21 Jul 2004 10:10:07 +0100 User-Agent: KMail/1.6.1 References: <20040720183213.GC1009@green.homeunix.org> <20040720185236.GD1009@green.homeunix.org> <40FD6E25.1080808@samsco.org> In-Reply-To: <40FD6E25.1080808@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407211010.08159.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 09:10:55 -0000 On Tuesday 20 July 2004 20:10, Scott Long wrote: > Brian Fundakowski Feldman wrote: > > On Tue, Jul 20, 2004 at 08:39:57PM +0200, Poul-Henning Kamp wrote: > >>In message <20040720183213.GC1009@green.homeunix.org>, Brian > >> Fundakowski Feldma > >> > >>n writes: > >>>On Tue, Jul 20, 2004 at 08:20:23PM +0200, Poul-Henning Kamp wrote: > >>>>I'm pulling hair out trying to make it guaranteed safe to unload > >>>> device driver modules, and the major pain here is to make sure > >>>> there is no thread stuck somewhere inside the code. > >>>> > >>>>That gave me the idea for a simple little DIAGNOSTIC check for > >>>> kldunload: run through the proc/thread table and look for any > >>>> thread with an instruction counter inside the range of pages we > >>>> are going to unload. > >>>> > >>>>Any takers ? > >>> > >>>You mean any thread with a stack trace that includes an > >>> instruction counter inside those pages, don't you? > >> > >>That would require us to unwind the stack which I think is overkill > >>for the purpose. > >> > >>The most likely case is that the thread is sleeping on something > >>inside the kld so just checking the instruction pointer would be > >>fine. > >> > >>Looking for sleep addresses inside the module might make sense too. > > > > It's probably not overkill -- at least in my experience most of the > > time a driver is "doing something" it is sleeping, so the address > > will be in mi_switch() or somewhere way out there. Sleep addresses > > on dynamic data addresses are also a lot more common than sleep > > addresses on static/code addresses. If someone is interested in > > doign this, it would be very informative, especially if it could > > catch sleeps, pending timeouts, pending callouts, etc. > > busdma callbacks, cam callbacks, netisr callbacks, and on and on and > on. The original intention was that drivers use the device_busy()/device_unbusy() counter to handle these things. In some cases, just calling device_busy() from fooopen() and device_unbusy() from fooclose() is sufficient.