On Tue, 23 Aug 2016, Mathias Nyman wrote: > The Dell XPS 9550 has an additional xhci controller for handling the type-C port. > This controller is hotplug removed from the PCI bus when the last USB type-c > device is disconnected. > > xhci driver, and usb core it seems is not really designed with this in mind. > xhci driver will suddenly start reading ffffffff from PCI. > > I've been looking at issues related to this. Currently there is at least one similar case with mass storage > where we see the device release function being called for the mass storage interface device _after_ we > freed all memory related to both xhci hcd's. bug for that is here: > > https://bugzilla.kernel.org/show_bug.cgi?id=120241 > > usb devices with their children should be synchronously removed before hcd's are freed, but seems > that is not the case, at least not for the device release function for the interface device. Be careful what words you use. USB devices and their children are indeed synchronously _removed_ before hcd's are freed. However, they may not be _released_ until later. What you encountered in that bug report was probably usb_release_dev() calling bus_to_hcd() and usb_put_hcd(). This action is part of a release, and it's allowed to happen long after everything has been removed (i.e., unregistered). Reference counting is supposed to keep everything important from being deallocated until all the releases are finished. In particular, if the hcd structure was already deallocated when usb_put_hcd() was called then there is a refcounting bug somewhere. > A horrible workaround to hide this issue was to sleep for a second or two before freeing the hcd memory, > this lets some pending work finish before hcds disappear. (more info in that bug report) The driver should synchronously cancel the work instead of sleeping. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
