Suspend to RAM was working fine on my Clevo N130WU laptop (Kaby Lake R i5-8250U, that laptop is commonly known under different names, like KDE Slimbook II, PCSpecialist 13.3" Lafite III or Obsidian N130WU) with the 4.18 kernel series and up until 4.19.5, but broke with the 4.19.6 update.
The laptop does not go into suspend anymore, the screen goes black for a short while, then the lock screen comes back up. The only unusual that I could find in
dmesg is something USB related:
dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16 PM: Device usb1 failed to suspend async: error -16 PM: Some devices failed to suspend, or early wake event detected
usb-devices does not reveal which device is identified as
dmesg (at least to me), but I assume it is the LTE modem (Huawei ME906s-158) which shows up as usb 1-2. Disabling XHC in
/proc/acpi/wakeup (which was the fix for immediate wakeup from suspend on 4.13 and 4.14 kernels) did not change anything.
Something strange when running
lsusb -v is the following second line shown for each device:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Couldn’t open device, some information will be missing
What I could find in the kernel changelog is:
Author: Mathias Nyman email@example.com
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. USB3 roothub might autosuspend before a plugged USB3 device is detected, causing USB3 device enumeration failure. USB3 devices don't show up as connected and enabled until USB3 link trainig completes. On a fast booting platform with a slow USB3 link training the link might reach the connected enabled state just as the bus is suspending. If this device is discovered first time by the xhci_bus_suspend() routine it will be put to U3 suspended state like the other ports which failed to suspend earlier. The hub thread will notice the connect change and resume the bus, moving the port back to U0 This U0 -> U3 -> U0 transition right after being connected seems to be too much for some devices, causing them to first go to SS.Inactive state, and finally end up stuck in a polling state with reset asserted Fix this by failing the bus suspend if a port has a connect change or is in a polling state in xhci_bus_suspend(). Don't do any port changes until all ports are checked, buffer all port changes and only write them in the end if suspend can proceed Cc: firstname.lastname@example.org Signed-off-by: Mathias Nyman <email@example.com> Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>