Re: kworker takes 100% core after unplugging usb c hub

From: Alan Stern <stern@rowland.harvard.edu>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Yiyu Zhu <danielzeltar@gmail.com>, Greg KH <greg@kroah.com>,
	linux-usb@vger.kernel.org
Subject: Re: kworker takes 100% core after unplugging usb c hub
Date: Thu, 4 Mar 2021 11:33:49 -0500	[thread overview]
Message-ID: <20210304163349.GC1612307@rowland.harvard.edu> (raw)
In-Reply-To: <546b9137-3054-4cb3-b085-e0ea32885e8a@linux.intel.com>

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