On Wed, 3 Sep 2014, Felipe Balbi wrote:
> Hi,
>
> I've been tracking down two issues and one of them seems to be a problem
> with either usbcore or xhci.
>
> DWC3, when acting as host, instantiates an xhci platform-device and sets
> itself as the parent of that. That's all fine and dandy until I try to
> modprobe -r dwc3.ko which causes XHCI to hang:
> | # modprobe -r dwc3
> | [ 53.016798] xhci-hcd xhci-hcd.0.auto: remove, state 4
> | [ 53.023083] usb usb2: USB disconnect, device number 1
> | [ 53.082845] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000 microseconds.
> | [ 53.090732] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
> | [ 53.112511] xhci-hcd xhci-hcd.0.auto: remove, state 1
> | [ 53.117883] usb usb1: USB disconnect, device number 1
> | [ 53.123301] usb 1-1: USB disconnect, device number 2
> | [ 53.128503] usb 1-1.6: USB disconnect, device number 3
> | [ 90.539781] INFO: task modprobe:1792 blocked for more than 30 seconds.
> | [ 90.546607] Not tainted 3.17.0-rc2-00004-ge0b64425 #800
> | [ 90.552672] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> | [ 90.560855] modprobe D c06bf5a0 0 1792 1662 0x00000000
> | [ 90.567541] [<c06bf5a0>] (__schedule) from [<c06bfa94>] (schedule+0x40/0x8c)
> | [ 90.574925] [<c06bfa94>] (schedule) from [<c06c3e48>] (schedule_timeout+0x154/0x220)
> | [ 90.583031] [<c06c3e48>] (schedule_timeout) from [<c06c0554>] (wait_for_common+0xdc/0x178)
> | [ 90.591672] [<c06c0554>] (wait_for_common) from [<c06c0610>] (wait_for_completion+0x20/0x24)
> | [ 90.600537] [<c06c0610>] (wait_for_completion) from [<bf0569d4>] (xhci_configure_endpoint+0xc8/0x590 [xhci_hcd])
> | [ 90.611226] [<bf0569d4>] (xhci_configure_endpoint [xhci_hcd]) from [<bf057664>] (xhci_check_bandwidth+0x16c/0x294 [xhci_hcd])
It sounds like unloading dwc3 breaks the communication with the
controller before it has been unbound from xhci. This is probably
caused by dwc3's removal routine doing something in the wrong order.
> This only happens when I have devices attached to the XHCI port on my
> platform (AM437x, but I suppose any XHCI would die similarly if you can
> destroy the underlying {platform,pci}_device.
It looks like dwc3/host.c:dwc3_host_exit() simply calls
platform_device_unregister(). That ought to work okay.
On the other hand, core.c:dwc3_remove() doesn't call
dwc3_core_exit_mode() until after doing a lot of other things.
Shouldn't it call dwc3_core_exit_mode() first?
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
