On 24.08.2016 17:14, Alan Stern wrote:
On Wed, 24 Aug 2016, Mathias Nyman wrote:
The sleep() worked as it delayed freeing the primary hcd, changing the
order to first release usb3 hcd and then usb2 hcd.
Does this mean that the patch you already posted is the proper fix?
Not sure, still just a step in the right direction.
"ab2a4bf USB: don't free bandwidth_mutex too early" seems to solve the other DELL XPS mass storage remove bug.
This Nexus 5 case still shows a locking issue after my patch. It ran a 4.7.2 kernel which should have your fix
included.
Jose Marino, could you try the patch on top of latest 4.8-rc3, just to make sure it's not some old issue?
About the locking issue, looks like we end up waiting forever for the device lock mutex:
[ 240.854069] INFO: task kworker/u16:31:970 blocked for more than 120 seconds.
[ 240.854070] Tainted: G W O 4.7.2-1-jose #1
[ 240.854074] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
[ 240.854076] Call Trace:
[ 240.854077] [<ffffffff815d31ec>] schedule+0x3c/0x90
[ 240.854078] [<ffffffff815d3595>] schedule_preempt_disabled+0x15/0x20
[ 240.854080] [<ffffffff815d4a5e>] __mutex_lock_slowpath+0xce/0x140
[ 240.854082] [<ffffffff815d4ae7>] mutex_lock+0x17/0x30
[ 240.854085] [<ffffffffa007c001>] usb_disconnect+0x51/0x2a0 [usbcore]
[ 240.854087] [<ffffffffa0082877>] usb_remove_hcd+0xc7/0x240 [usbcore]
[ 240.854090] [<ffffffffa009467f>] usb_hcd_pci_remove+0x6f/0x140 [usbcore]
[ 240.854091] [<ffffffffa016c1c5>] xhci_pci_remove+0x55/0x70 [xhci_pci]
(Just one sample, there were many blocked tasks)
-Mathias
--
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
