HI,
On Wed, Sep 03, 2014 at 03:47:16PM -0500, Felipe Balbi wrote:
> 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 :-)
yup, works like a charm. Thanks. Can I add your Suggested-by or
something else ?
cheers
--
balbi
Attachment:
signature.asc
Description: Digital signature
