Hi,
On Wed, Sep 03, 2014 at 04:41:34PM -0400, Alan Stern wrote:
> 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.
HAH! I guess you just found the issue for me :-) We're killing the PHYs
as the first step, before even trying to unregister XHCI's
platform_device.
> > 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?
yup. At least the PHYs still need to the be alive for as long as XHCI is
:-)
Let me try that out. There's nothing an extra set of eyes :-)
--
balbi
Attachment:
signature.asc
Description: Digital signature
