Bug 197863

Summary: Thinkpad X240 resume dramatically slower on kernels 4.13+
Product: ACPI Reporter: Martin Demlon (m)
Component: ECAssignee: Rafael J. Wysocki (rjw)
Status: RESOLVED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: lenb, rjw, yu.c.chen
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.15 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: dmesg excerpt of a "hanging" resume

Description Martin Demlon 2017-11-13 19:40:57 UTC
Created attachment 260641 [details]
dmesg excerpt of a "hanging" resume

Until kernel 2.12, resume from suspend (to RAM) was quick on my Thinkpad X240 (roughly 1 second).  Starting with kernel 4.13.0, it takes about 10 seconds for the machine to become responsive.

The screen is back as fast as before, showing the expected image, both with X and in a console, but keyboard and mouse events are not processed (I'd speculate that the USB timeout at 45.812 in in the attached dmesg output is related to that) until much later.

I'm using Debian pm-utils to suspend and resume, but the phenomenon is not noticably different when just using echo mem > /sys/power/state, and it is back to quick resume when I boot a 4.12 kernel again.

The attached dmesg exceprt shows a suspend-resume cycle on a freshly booted, self-built 2.14 kernel.  The machine has the usual X240 components plus an optional Sierra LTE modem; lsusb on the fully resumed machine looks like this:

Bus 003 Device 002: ID 8087:8000 Intel Corp. 
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04f2:b39a Chicony Electronics Co., Ltd 
Bus 001 Device 002: ID 1199:a001 Sierra Wireless, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Comment 1 Chen Yu 2017-11-20 09:02:46 UTC
I think your speculation is right, the xhci has taken too much time for a reset:
[   39.292052] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
[   45.812046] usb 1-4: device descriptor read/64, error -110
[   46.262082] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
I don't know if it should be reset in this case, let me switch to usb component for suggestion.
Comment 2 Greg Kroah-Hartman 2017-11-20 11:24:09 UTC
On Mon, Nov 20, 2017 at 09:02:46AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> I think your speculation is right, the xhci has taken too much time for a
> reset:
> [   39.292052] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
> [   45.812046] usb 1-4: device descriptor read/64, error -110
> [   46.262082] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
> I don't know if it should be reset in this case, let me switch to usb
> component
> for suggestion.


All USB bugs should be sent to the linux-usb@vger.kernel.org mailing
list, and not entered into bugzilla.  Please bring this issue up there,
if it is still a problem in the latest kernel release.
Comment 3 Rafael J. Wysocki 2018-02-09 21:32:16 UTC
Patch posted and tested: https://patchwork.kernel.org/patch/10207819/