On Wed, 7 Sep 2016, Mathias Nyman wrote: > > I'm still seeing occasional problems. For example, when I unplugged the dock last night, it seems to have wedged some things, and then plugging it back in didn't work. See some logs below. > > > > > > I ran a show-blocked-tasks after plugging the dock back in: > > > > Looks like there is the usb_hub_wq that tries to handle the disconnect event > at the same time as the pci remove code is removing xhci hosts (and connected devices) > > > Sep 7 09:03:30 fred kernel: [83879.383356] Workqueue: usb_hub_wq hub_event > > Sep 7 09:03:30 fred kernel: [83879.383395] Call Trace: > > Sep 7 09:03:30 fred kernel: [83879.383416] [<ffffffff81855fa5>] schedule+0x35/0x80 > > Sep 7 09:03:30 fred kernel: [83879.383427] [<ffffffff8163433d>] usb_kill_urb+0x8d/0xc0 > > Sep 7 09:03:30 fred kernel: [83879.383444] [<ffffffff810c4490>] ? wake_atomic_t_function+0x60/0x60 > > Sep 7 09:03:30 fred kernel: [83879.383454] [<ffffffff81633076>] usb_hcd_flush_endpoint+0x126/0x190 > > Sep 7 09:03:30 fred kernel: [83879.383465] [<ffffffff81635fbb>] usb_disable_endpoint+0x9b/0xb0 > > > > Sep 7 09:03:30 fred kernel: [83879.383686] Workqueue: kacpi_hotplug acpi_hotplug_work_fn > > Sep 7 09:03:30 fred kernel: [83879.383717] Call Trace: > > Sep 7 09:03:30 fred kernel: [83879.383728] [<ffffffff81855fa5>] schedule+0x35/0x80 > > Sep 7 09:03:30 fred kernel: [83879.383738] [<ffffffff8185624e>] schedule_preempt_disabled+0xe/0x10 > > Sep 7 09:03:30 fred kernel: [83879.383748] [<ffffffff81857ea9>] __mutex_lock_slowpath+0xb9/0x130 > > Sep 7 09:03:30 fred kernel: [83879.383758] [<ffffffff81857f3f>] mutex_lock+0x1f/0x30 > > Sep 7 09:03:30 fred kernel: [83879.383766] [<ffffffff8162b951>] usb_disconnect+0x51/0x280 > > Sep 7 09:03:30 fred kernel: [83879.383776] [<ffffffff816314f0>] usb_remove_hcd+0xd0/0x240 > > First guess would be there is something wrong with killing the urb. > usb_hub_wq takes the roothub device lock first, and then ends up waiting for usb_kill_urb forever. I agree. Probably xhci-hcd is waiting for the controller to do something before it will give back the cancelled URB. But since the controller has been removed, it never does anything. > This would block the pci remove path when usb_remove_hcd calls usb_disconnect, which > tries to take the roothub lock as well. > > Doing a usbfs read on a usb device also takes the roothub device lock, which could explain > why lsusb is blocked. > > Just an idea, need to check the code in more detail to see if it's a possible cause ehci-hcd includes checks in several places for ehci->rh_state == RH_STATE_RUNNING. The removal pathway sets ehci->rh_state to RH_STATE_HALTED. As a result, the driver avoids waiting for things that will never happen. 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
