From owner-freebsd-arch@FreeBSD.ORG  Wed Jul 21 07:06:39 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 9221816A4CF; Wed, 21 Jul 2004 07:06:39 +0000 (GMT)
Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net
	[207.115.63.102])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 49A4543D60; Wed, 21 Jul 2004 07:06:39 +0000 (GMT)
	(envelope-from julian@elischer.org)
Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net
	[68.121.219.69])i6L76blM027296;	Wed, 21 Jul 2004 03:06:37 -0400
Message-ID: <40FE15FD.904@elischer.org>
Date: Wed, 21 Jul 2004 00:06:37 -0700
From: Julian Elischer <julian@elischer.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524
X-Accept-Language: en, hu
MIME-Version: 1.0
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
References: <77806.1090392273@critter.freebsd.dk>
In-Reply-To: <77806.1090392273@critter.freebsd.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: David Schultz <das@freebsd.org>
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
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2004 07:06:39 -0000

Poul-Henning Kamp wrote:

>In message <20040720203739.GA72252@VARK.homeunix.com>, David Schultz writes:
>
>  
>
>>>Looking for sleep addresses inside the module might make sense too.
>>>      
>>>
>>But this is just a heuristic that may sometimes fail.  The module
>>might be holding resources or locks, it could have callbacks, etc.
>>If we're going to offer a forcible unload option, [...]
>>    
>>
>
>This has _nothing_ to do with forcible unload.
>
>Please read the subject, again if necessary.
>
>This is an idea for a debug tool which may help people properly
>debug and implement unload *in general*.
>

as such, speed wouldnot be crucial, so having an alterred version of the 
stack trace code
that walks all available stacks looking for matching addresses would be 
quite a reasonable thingto do.

>
>  
>