On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman wrote: > On 10.11.2016 13:22, Oliver Neukum wrote: >> >> On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote: >>> >>> Kai-Heng Feng writes: >>>> >>>> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote: >>>>> >>>>> Oliver Neukum writes: >>>>> >>>>>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote: >>>>>> >>>>>>> These problems could very well be caused by running at SuperSpeed >>>>>>> (USB-3) instead of high speed (USB-2). >>>> >>>> >>>> Yes, it's running at SuperSpeed, on a Kabylake laptop. >>>> >>>> It does not have this issue on a Broadwell laptop, also running at >>>> SuperSpeed. >>> >>> >>> Then I must join Oliver, being very surprised by where in the stack you >>> attempt to fix the issue. What you write above indicates a problem in >>> pci bridge or usb host controller, doesn't it? Yes, I was totally wrong about that. >> >> >> Indeed. And this means we need an XHCI specialist. >> Mathias, we have a failure specific to one implementation of XHCI. >> > > > Could be related to resume singnalling time. > Does the xhci fix for it in 4.9-rc3 help? > > commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 > xhci: use default USB_RESUME_TIMEOUT when resuming ports. > > It doesn't directly explain why it would work on Broadwell but not Kabylake, > but it resolved very similar cases. > > If not, then adding dynamic debug for xhci could show something. I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7, on for-usb-next branch. Now the cdc_mbim still probe failed at the first time, but somehow it re-probed again with a success. I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the behavior is the same, first time probed failed, second time probed success. The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled. > > -Mathias >