On Fri, 27 Jan 2017, John Youn wrote: ...
> >>>>>>>>>> [ 31.368022] hub 6-0:1.0: hub_resume > >>>>>>>>>> [ 31.368064] xhci-hcd xhci-hcd.0.auto: get port status, actual > >>>>>>>>>> port 0 status = 0x400340 > >>>>>>>>>> [ 31.368071] xhci-hcd xhci-hcd.0.auto: Get port status returned > >>>>>>>>>> 0x400340 > >>>>>>>>>> [ 31.368224] hub 6-0:1.0: state 7 ports 1 chg 0000 evt 0000 > >>>>>>>>> > >>>>>>>>> Looks like port is stuck in Compliance mode, this should only > >>>>>>>>> happen if a connect was detected, > >>>>>>>>> moving the port from RxDetect to Polling, and then timeout on > >>>>>>>>> polling to get to compliance. > >>>>>>>>> > >>>>>>>>> 4.9 is then stuck in a hub_suspend/resume loop with a port in > >>>>>>>>> compliance mode. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> v4.10-rc1 dmesg logs : > >>>>>>>>>> > >>>>>>>>>> .... > >>>>>>>>>> [ 269.436617] usb usb6-port1: cannot disable (err = -32) > >>>>>>>>>> [ 269.464728] hub 6-0:1.0: state 7 ports 1 chg 0000 evt 0002 > >>>>>>>>>> [ 269.464756] xhci-hcd xhci-hcd.0.auto: get port status, actual > >>>>>>>>>> port 0 status = 0x340 > >>>>>>>>> > >>>>>>>>> I 4.10-rc1 we are again stuck in Compliance mode, but this time > >>>>>>>>> there was a event (00002) visible, maybe because > >>>>>>>>> the flags were not cleared or some other reason. Now are stuck in a > >>>>>>>>> port reset loop with the > >>>>>>>>> port in compliance mode. > >>>>>>>>> So the real question is why is the port in compliance mode when > >>>>>>>>> there are no devices connected.? ... > > John, another instance of SUSPHY bit messing up with host side :-s > > What is the exact failure? Is it a command timing out after going into > U3 like before? As you can see above, the problem was that the port was stuck in Compliance mode. Even though nothing was connected to it. (These messages were hidden in the rather lengthy quoted portion of the email message. My contribution to this thread is simply to trim out the uninteresting parts.) Alan Stern > Typically the PHY going to U3 should not affect the controller. But > there could be a design issue. For example if the RAM clock is derived > from the PHY clock. Again check the design and the GCTL.RAMCLKSEL. > > Another possibility is if the driver tries to issue a command to the > controller that requires the link when in U3. But we've never seen > this. > > Regards, > John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
