On Fri, Mar 05, 2021 at 11:04:52AM +0200, Mathias Nyman wrote: > 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? Or perhaps the hub communicates okay over the SS wires but causes an overcurrent on the USB-2 D+/D- wires. Either way, it sounds like a hardware problem in that hub. Alan Stern
