On 04.02.2019 17:27, Alan Stern wrote:
On Mon, 4 Feb 2019, Mathias Nyman wrote:
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)?
I would prefer to see the underlying cause for this problem figured
out. Why is the USB3 port stuck in polling mode? Is it a hardware
issue or a software bug?
More detailed debugging logs might help.
Eric, can you take logs of this?
For adding xhci tracing
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
after failed suspend attempt show /sys/kernel/debug/tracing/trace
For adding xhci and usb core dynamic debug:
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
-Mathias
