On 04.02.2019 15:17, Eric Blau wrote:
On Mon, Feb 4, 2019 at 8:12 AM Eric Blau <eblau@xxxxxxxxx> wrote:
On Mon, Feb 4, 2019 at 4:31 AM Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> wrote:
On 03.02.2019 04:08, Eric Blau wrote:
I finally was able to complete the bisect on this issue. It seems that
this commit introduced the regression on my MacBook Pro:
cc8b329fef53c74a4abf98b0755b3832d572d6ce is the first bad commit
commit cc8b329fef53c74a4abf98b0755b3832d572d6ce
Author: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Date: Thu Nov 15 11:38:41 2018 +0200
usb: xhci: Prevent bus suspend if a port connect change or polling
state is detected
commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.
There's an additional fix for that patch, in 4.19 stable:
commit e13bfb357f5bc04f9e7ccff7d07770388062a8cc
Author: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
Date: Fri Dec 14 10:54:43 2018 +0200
xhci: Don't prevent USB2 bus suspend in state check intended for USB3 only
commit 45f750c16cae3625014c14c77bd9005eda975d35 upstream.
If you already have that fix then one of the USB ports may be in a odd state when suspending
Does adding dynamic debug for xhci_hub_control show any messages when suspending?
mount -t debugfs none /sys/kernel/debug
echo -n 'func xhci_bus_suspend =p' > /sys/kernel/debug/dynamic_debug/control
Hi Mathias,
I see this behavior even in 4.20.6. With the above commit reverted, my
laptop suspends and resumes properly again and I don't see the high
CPU usage of the mentioned kernel threads.
When I suspend with the dynamic debugging enabled on 4.20.6, I see a
flood of xhci_hcd messages like the following:
Feb 04 08:06:44 eric-macbookpro kernel: xhci_hcd 0000:00:14.0: Bus
suspend bailout, port in polling
Ok, 4.20.6 has the 45f750c16cae "Don't prevent USB2 bus suspend" fix in,
so seems a USB3 port is stuck in polling mode in some cases, preventing suspend.
Original patch was meant to prevent runtime suspend in case a newly attached USB3
device was slow to enumerate, but same code is called for system suspend.
The original patch could be limited to runtime suspend only, but looks like that
requires usb core change.
hcd->driver->bus_suspend(hcd) callback needs to provide pm_message_t as a parameter.
Alan, would it make sense to let host controller drivers decide to prevent bus_suspend
based on port states and pm message type (runtime or system suspend)?
-Mathias
