From owner-freebsd-new-bus Fri Dec 3 1:12: 4 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 50BA8150BE for ; Fri, 3 Dec 1999 01:11:41 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA57597; Fri, 3 Dec 1999 09:18:36 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 3 Dec 1999 09:18:36 +0000 (GMT) From: Doug Rabson To: Nick Hibma Cc: FreeBSD Newbus Mailing List Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Dec 1999, Nick Hibma wrote: > > > device_detach deletes the softc allocated for the device. > > > Drivers cache copies of softc in their ISRs and other places where > > > they sleep and count on the cached copy of softc to still be around > > > when they are woken up. If a pccard is ejected between these points, > > > these cached copies disappear because the ejection code deletes the > > > device from the device tree (an as a side effect calls detach, which > > > frees the softc for the device). > > > > > > Suspend has a similar problem because it can come in while a > > > device is sleeping. > > > > The device_detach routine *must* teardown all interrupt handlers and > > release all resources. If this rule is followed, then the handler > > shouldn't be called after detach, so there is no problem, right? > > The problem is that the following occurs now: > > DEVICE_DETACH called from device_delete_child wakes up all the sleepers > and exits. The sleepers actually start running after DEVICE_DETACH has > finished and the softc has been blown away by the device_delete_child > that followed. > > I think this cries for a loop: Call detach and if EAGAIN is returned > make sure sleepers can wake up and exit, and then try again. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I have no idea how this 'wait for sleepers to have run' could be > implemented, but this is I think the crucial part. I think that the solution is probably to use the busy counter more effectively. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message