Date: Sat, 14 Jun 2003 21:24:39 -0500 From: Craig Boston <craig@xfoil.gank.org> To: ticso@cicely.de, Bernd Walter <ticso@cicely12.cicely.de> Cc: current@freebsd.org Subject: Re: O(/E)HCI detach support Message-ID: <200306142124.39356.craig@xfoil.gank.org> In-Reply-To: <200306141902.52925.craig@xfoil.gank.org> References: <1055260269.91337.127.camel@owen1492.uf.corelab.com> <20030612121514.GD26807@cicely12.cicely.de> <200306141902.52925.craig@xfoil.gank.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306142124.39356.craig>