Bug 197863
| Summary: | Thinkpad X240 resume dramatically slower on kernels 4.13+ | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Martin Demlon (m) |
| Component: | EC | Assignee: | 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 | ||
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. 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. Patch posted and tested: https://patchwork.kernel.org/patch/10207819/ |
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