Bug 197863 - Thinkpad X240 resume dramatically slower on kernels 4.13+
Summary: Thinkpad X240 resume dramatically slower on kernels 4.13+
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-13 19:40 UTC by Martin Demlon
Modified: 2018-02-09 21:32 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.15
Tree: Mainline
Regression: Yes


Attachments
dmesg excerpt of a "hanging" resume (3.38 KB, text/plain)
2017-11-13 19:40 UTC, Martin Demlon
Details

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/

Note You need to log in before you can comment on or make changes to this bug.