On 07.09.2016 11:46, Richard van der Hoff wrote:
On 01/09/16 08:53, Richard van der Hoff wrote:
On 30/08/16 21:52, Richard van der Hoff wrote:
On 30/08/16 19:48, Alan Stern wrote:
On Tue, 30 Aug 2016, Richard van der Hoff wrote:
I have a USB-3.1 dock; sometimes I see a kernel panic when I unplug it,
which hangs the entire system. It appears that the first unplug is
successful; the second one normally triggers a crash.
Please try applying the patch at the bottom of this email:
http://marc.info/?l=linux-usb&m=147195533502706&w=2
There's a good chance it will fix your problem.
Is there a plan to merge this patch? It certainly seems to help.
I'll send it to Greg. Maybe it can make it to 4.8 as there's already two real world cases of
this NULL pointer dereference.
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.
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
-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
