On 4.3.2021 18.33, Alan Stern wrote: > On Thu, Mar 04, 2021 at 06:31:47PM +0200, Mathias Nyman wrote: >> Hi >> >> On 2.3.2021 8.25, Yiyu Zhu wrote: >>> Hi Mathias, >>> >>> I did not set the correct printk value. Here is a recent dmesg showing >>> the hub connection and disconnection on Linux 5.11.0. >>> >> ... >>> [ 1662.620564] usb usb3: usb wakeup-resume >>> [ 1662.620570] usb usb3: usb auto-resume >>> [ 1662.620585] hub 3-0:1.0: hub_resume >>> [ 1662.620607] hub 3-0:1.0: state 7 ports 2 chg 0002 evt 0000 >>> [ 1662.620637] usb usb3-port1: over-current change #1 >>> [ 1662.724578] hub 3-0:1.0: trying to enable port power on non-switchable hub >>> [ 1662.832221] usb usb3-port1: over-current condition >>> [ 1662.832237] usb usb3-port1: status 0008, change 0008, 12 Mb/s >>> [ 1662.832262] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000 >>> [ 1662.832277] hub 3-0:1.0: hub_suspend >>> [ 1662.832297] usb usb3: bus auto-suspend, wakeup 1 >>> [ 1662.832307] usb usb3: bus suspend fail, err -16 >>> [ 1662.832313] hub 3-0:1.0: hub_resume >>> [ 1662.832344] hub 3-0:1.0: state 7 ports 2 chg 0002 evt 0000 >>> [ 1662.832363] usb usb3-port1: status 0008, change 0000, 12 Mb/s >>> [ 1662.832375] hub 3-0:1.0: hub_suspend >>> [ 1662.832388] usb usb3: bus auto-suspend, wakeup 1 >>> [ 1662.832397] usb usb3: bus suspend fail, err -16 >>> [ 1662.832402] hub 3-0:1.0: hub_resume >> (removed some messages from other buses from above snippet) >> >> Looks like the suspend/resume loop is triggered by an over-current event. >> hub wq notices there is a over-current change, and an over-current status (two separate bits) >> hub wq clears the change bit, tries to resolve the over-current, fails, and continues. >> >> This hub (roothub) has no other children or activity so it runtime suspends. >> After this the bus tries to suspend, but it fails as xhci bus_suspend() >> returns -EBUSY if a port is in over-current state. >> >> Hub is woken up. hub wq runs, this time there is no over-current change >> bit set as it was cleared earlier. The over-current status is still active. >> Hub wq doesn't see any activity, hub is suspended -> try to suspend bus -> fail... >> >> Solution is still unclear, maybe hub wq should react to over-current states, >> not just changes? > > Your analysis seems to point to a hardware problem. If nothing is > plugged into the root hub, it should not report an over-current state. > > Alan Stern Hmm, true, logs doesn't show anything connected to usb 3 (HS) bus roothub, but on the usb4 (SS) bus roothub there is a USB 3.0 external hub connected. [ 1650.115544] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1650.115545] usb 4-1: Product: 4-Port USB 3.0 Hub [ 1650.115547] usb 4-1: Manufacturer: Generic So there should be a HS hub on usb 3-1, (same connector as the SS side usb 4-1) but instead we just see the over-current error. xHCI will set a HS port that has an over-current condition to a powered-off state with link state to Disabled, and port powered off, so no device will appear connected. Maybe the enumerated SS HUB on usb 4-1 is draining more power from the connector than the un-enumerated HS hub is allowed, causing the the over-current for HS the port? -Mathias
