From owner-freebsd-current@FreeBSD.ORG Sat Jun 14 19:24:41 2003 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 9C95537B401; Sat, 14 Jun 2003 19:24:41 -0700 (PDT) Received: from ion.gank.org (ion.gank.org [198.78.66.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6F9C43FBD; Sat, 14 Jun 2003 19:24:40 -0700 (PDT) (envelope-from craig@xfoil.gank.org) Received: from localhost (ion.gank.org [198.78.66.164]) by ion.gank.org (GankMail) with ESMTP id C85352C957; Sat, 14 Jun 2003 21:24:40 -0500 (CDT) Received: from ion.gank.org ([198.78.66.164]) by localhost (ion.gank.org [198.78.66.164]) (amavisd-new, port 10024) with LMTP id 65587-07; Sat, 14 Jun 2003 21:24:40 -0500 (CDT) Received: from aldaris2.auir.gank.org (dsl081-113-221.dfw1.dsl.speakeasy.net [64.81.113.221]) by ion.gank.org (GankMail) with ESMTP id B8C982BC5A; Sat, 14 Jun 2003 21:24:39 -0500 (CDT) From: Craig Boston To: ticso@cicely.de, Bernd Walter Date: Sat, 14 Jun 2003 21:24:39 -0500 User-Agent: KMail/1.5.2 References: <1055260269.91337.127.camel@owen1492.uf.corelab.com> <20030612121514.GD26807@cicely12.cicely.de> <200306141902.52925.craig@xfoil.gank.org> In-Reply-To: <200306141902.52925.craig@xfoil.gank.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306142124.39356.craig@xfoil.gank.org> cc: Josef Karthauser cc: current@freebsd.org Subject: Re: O(/E)HCI detach support 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: Sun, 15 Jun 2003 02:24:41 -0000 Okay, sorry for the reply-to-self, but I think I've nailed down the detach problem and it looks like it will require some more work. In short, the OHCI driver may be ready for hot-plugging but the USB subsystem isn't. Here's a play-by-play of what's happening: 1. On card removal, cardbus_detach_card dispatches ohci_pci_detach 2. ohci_pci_detach calls device_delete_child on itself 3. device_delete_child calls itself recursively for the children of ohci 4. When device_delete_child tries to dispatch device_detach for the first uhub it finds, it gets ENXIO because uhub doesn't define a detach method 5. The ENXIO error filters up to the top level device_delete_child and it exits without detaching any of the other devices 6. ohci_pci_detach ignores the error result and removes all its resources (about all it can do at this point) 7. cardbus_detach_card removes the PCI configuration data from memory This leaves some nonexistent devices as children of the cardbus device. The next time any card is inserted, it calls cardbus_detach_card to remove the old entries, which removes the already-removed PCI config, and BOOM. I think the only way this can be resolved is to make sure all of the USB-related devices (including the root hub) have a device_detach method implemented. uhub is easy enough to fix -- like OHCI and EHCI it has a detach function written but it's just not referenced in the device_method_t. The usb device is a whole can of worms though. It has a detach method that just spits out "unload prevented" and returns EINVAL. Of course since the usb bus has physically been removed it doesn't have much of a choice :). I put in a null function that just returns 0 as a test, but it either panics immediately because the event thread is still polling the device or panics when you put the card back in and it tries to make_dev something that already exists ("panic: don't do that"). It looks like the NetBSD and OpenBSD cases do have detach code, so it may just be a matter of modifying that remove the device entry. If I get some free time tomorrow I'll take a crack at it and see how many times I can panic this poor laptop :D Craig