From owner-freebsd-current@FreeBSD.ORG Mon Jul 19 17:44:24 2004 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 1BA2316A4CE; Mon, 19 Jul 2004 17:44:24 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C1843D41; Mon, 19 Jul 2004 17:44:23 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6JHoMlE054714; Mon, 19 Jul 2004 11:50:22 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40FC0832.3040805@freebsd.org> Date: Mon, 19 Jul 2004 11:43:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20040719145745.GH57678@darkness.comp.waw.pl> <20040719102139.N59702@carver.gumbysoft.com> <20040719173819.GI57678@darkness.comp.waw.pl> In-Reply-To: <20040719173819.GI57678@darkness.comp.waw.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: Unloading USB driver while device is attached. 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, 19 Jul 2004 17:44:24 -0000 Pawel Jakub Dawidek wrote: > On Mon, Jul 19, 2004 at 10:23:16AM -0700, Doug White wrote: > +> Theres a discussion going on in -arch about making kldunload a bit more > +> careful about cleaning up before detaching. In the interim adding a > +> method that just vetos any unload request would prevent this from > +> occuring, but also preclude unloading the driver. :) > > Yeah, but even on 'kldunload -f' it should be possible to clean up > and avoid panic on next load. > What usually happens in that a timeout happens and the driver handler no longer exists (i.e. forgot to call untimeout), or an interrupt happens and the driver forgot to deregister the interrupt. There are also a lot of rase possibilities in here even if the driver attempts to do the right thing. There really isn't a 'one size fits all' way to deal with this kind of thing. The driver author needs to build quiesce and shutdown semantics into the driver design. Scott