From owner-freebsd-current Wed Dec 1 12: 7: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id F3B251511E; Wed, 1 Dec 1999 12:06:37 -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 UAA69019; Wed, 1 Dec 1999 20:12:32 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 1 Dec 1999 20:12:32 +0000 (GMT) From: Doug Rabson To: Mike Smith Cc: Warner Losh , Christopher Masto , Nick Hibma , FreeBSD CURRENT Mailing List Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: <199911302335.PAA02844@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Nov 1999, Mike Smith wrote: > > Hmmm... That's something... How do you know that the delete_child is > > failing? An if printing that it failed or conjecture based on the > > insertion results? > > You should definitely check the delete result, yes. > > Also, are you calling bus_generic_detach() after deleting the child? > I got the impression from Doug that this is required... Nonono. If you call bus_generic_detach from anywhere, call it from ep_detach(). Don't call bus_generic_anything() outside the implementation of a driver. The device_delete_child() call implies a call to device_detach() which *may* use bus_generic_detach() to do some of its work. -- 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-current" in the body of the message