Suspend fails in Kubuntu 18.04 but works fine in Kubuntu 17.10

[Carsten Gräser]

After upgrading to kubuntu 18.04 resuming from suspend fails in most cases on my laptop. When trying to resume the power LED is turned on, but the screen stays black and the system does not respond at all. Switching to another virtual terminal is not possible and closing the lid again does not show any effect. The hardware is a Dell Latitude e7440 with core i7 4600U and intel graphics only. The only way to change the status is a hard shut-down by long pressing the power button. The last message in kern.log is:

PM: suspend entry (deep)

The described problem is similar to bug #1774950. However, the latter is considered to be fixed with kernel 4.15.0-38 while my problem persists with this kernel.

Output of 'sudo lspci -vnvn' is attached, the result of 'cat /proc/version_signature' is:

Ubuntu 4.15.0-38.41-generic 4.15.18
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: graeser 2116 F.... pulseaudio
 /dev/snd/controlC0: graeser 2116 F.... pulseaudio
CurrentDesktop: KDE
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-precise-amd64-20130203-1
DistroRelease: Ubuntu 18.04
EcryptfsInUse: Yes
HibernationDevice: RESUME=none
InstallationDate: Installed on 2014-03-20 (1690 days ago)
InstallationMedia: Ubuntu 12.04 "Precise" - Build amd64 LIVE Binary 20130203-13:50
MachineType: Dell Inc. Latitude E7440
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic root=UUID=25e09413-4977-401f-a034-0465b444518b ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-38-generic N/A
 linux-backports-modules-4.15.0-38-generic N/A
 linux-firmware 1.173.1
Tags: bionic
Uname: Linux 4.15.0-38-generic x86_64
UpgradeStatus: Upgraded to bionic on 2018-10-15 (20 days ago)
UserGroups: adm cdrom dip docker lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 02/02/2015
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A14
dmi.board.name: 0WK2DM
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA14:bd02/02/2015:svnDellInc.:pnLatitudeE7440:pvr01:rvnDellInc.:rn0WK2DM:rvr:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E7440
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1801743

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Carsten Gräser (graeser)]

apport information

[Cristian Aravena Romero (caravena)]

Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:
'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as
"Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.1

[Carsten Gräser (graeser)]

Yes the issue did not happen prior to the update to 18.04. But I don't know if there was a prior kernel in 18.04 where the issue did not occur, because it's not happening 100% of the time. Still a successful resume is rare.

I'll give the mainline kernel a try.

[Carsten Gräser (graeser)]

The mainline kernel indeed seems to fix the issue: Not a single failed suspend/resume cycle since using 4.19.1.

[Igors (igors-mihailovs0)]

Unfortunately, not for me. We have a bunch of (theoretically) identical computers in a new classroom, and on one of them this issue is present. Similarly as described by Carsten Gräser (graeser): last entry in kern.log, running fan and no reaction to either keyboard or power button, last message on screen being

A start job is running for Hold until boot process finishes up (21s / no limit).

Only the power button is blinking, not steady, and with addition of similar problems at the shutdown (NOT at the reboot, except for the long delay). It seems that the system thinks from certain gauges that it is suspended or powered down, but some part of it is not. Last message for the failed shutdown is

reboot: Power down

and then everything stays as if there would be the classic message "It's now safe to power off Your computer", with screen on and fan running.

To reinstate, installing the upstream kernel 4.19.1 did not help on this issue. Some 30 PCs of identical hardware do not have this problem.

[Igors (igors-mihailovs0)]

Last entry in /var/log/kern.log for the incomplete shutdown seems to be

rfkill: input handler enabled

This is the last line before timings went to zeros last time, and it was just 1 second before the line "Stopping system logging service" in the syslog.

lspci -v output:
https://pastebin.com/S2yGLfAE

[Nadi (nadi-bar)]

Hei,
I have the same problem as Carsten Gräser (graeser), and in fact a similar laptop (Dell Latitude 7390).
I tried all the possible kernels since 4.14 to 4.19, and suspend (sleep S3) does not work. Same symptoms: It suspends when I close the lid, but cannot resume. When I open the lid and press the power button, it flushes ones but the screen is black. No response, no mouse, all dead. The only solution is to press again on the power button which performs hard reset.

Important comment: when I suspend from the function key (Fn-suspend) it works, but only for a short time (less than a minute): after some time (I did not manage to find out exactly how many minutes) it cannot resume. When I close the lid, it fails compelety does not matter how long I wait. Strange!

Currently using
Linux version 4.19.7-041907-generic (kernel@kathleen) (gcc version 8.2.0 (Ubuntu 8.2.0-10ubuntu1)) #201812052010 SMP Wed Dec 5 20:11:58 UTC 2018

Tried 18.04 and than upgraded to 18.10, still the same problem.
This is my hardware:
barc@NTNU15333:~$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08)
00:13.0 Non-VGA unclassified device: Intel Corporation Sunrise Point-LP Integrated Sensor Hub (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:15.2 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #2 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1c.7 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #8 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Intel(R) 100 Series Chipset Family LPC Controller/eSPI Controller - 9D4E (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
6c:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
6d:00.0 Non-Volatile memory controller: SK hynix Device 1527

Thank you!

[Magnus Breder Birkenes (magnusbb)]

This bug affects me as well, on a Dell Latitude E7440 (is this a Dell problem?). In my case, the bug started to appear with kernel 4.15.0-36 (and has been present in all later updates), both on 16.04 with the latest HWE and now with 18.04. For the time being I am using kernel 4.15.0-34, which is stable.

[Nadi (nadi-bar)]

Hei Magnus,
What do you mean "which is stable"? can you put the computer in Sleep mode (S3) and it recovers?
Does it wakes when you open the lid, or do you have to press the button then it wakes?
Thanks

[Magnus Breder Birkenes (magnusbb)]

Hei Nadi,

sorry, that was rather vague. Yes, by that I mean that it does wake up from sleep, and it does wake up immediately when I open the lid. When using 4.15.0-36 or later, on the other hand, sleep is not reliable. It may work, but most times it does not.

Magnus

[Nadi (nadi-bar)]

I tried to change the swap size to 8 GB (I have 16GB RAM), and confirmed that my swap is 8GB:

bar@NTNU15333:~$ grep SwapTotal /proc/meminfo
SwapTotal: 8388604 kB

but sleep by closing the lid still crash when I try to wake it (opening the lid, pressing the power button). It flashes one, then dead. Next press in the power restarts the computer.

[Nadi (nadi-bar)]

OK, I think I progressed a bit:

SUPER STRANGELY, awaking from sleep crashes only when I close the lid. My Dell latitude has Fn-sleep combo so I can suspend the laptop from the jeyboard, and then I have no crash. I tried several times and it repeatedly wakes up without problems.

BUT if I close the lid after the suspend (also when I suspend from the keyboard Fn combination), the laptop crashes when tries to wake. I can reproduce this.
Googling around, I did not find any solution in linux, but several had the same problem in Windows: https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/workstation-crashes-sometimes-when-lid-is-closed/2c3c38a7-dee7-4ee8-a233-a5031f59110c

Which microsoft suggest waking USB driver, perhaps it is Intel USB 3.0 driver.
I will update the BIOS and if the problem persists, I will open a new bug report.

[Nadi (nadi-bar)]

I updated the BIOS but it did not help....

but I SOLVED my problem, and perhaps yours as well Magnus!
The problem was with the LID upon waking up from sleep S3.
I found it after hours of googling and eventually debugging using this link:
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues

I cancelled the ACPI that enables the lid:
echo LID0 > /proc/acpi/wakeup
which turns the disabels the lid signal to the ACPI. It is problably doing something wrong, I will try to file a new bug soon.

This is the relevant output of the wakeup file:

XHC S0 *enabled pci:0000:00:14.0
XDCI S4 *disabled
HDAS S4 *disabled pci:0000:00:1f.3
LID0 S3 *disabled platform:PNP0C0D:00
PBTN S3 *enabled platform:PNP0C0C:00

Every boot I have to re-disable it, so I make a small script and used crontab -e, and added the this line to the end of the script:
@reboot /usr/local/bin/myFixScript.sh
see the link
https://www.kompulsa.com/run-a-program-on-startup-console-on-ubuntu-18-04/

Lets see how long it will be stable :-)
Cheers...
Nadi

[Magnus Breder Birkenes (magnusbb)]

Thanks for this, nadi!

I applied your fix using a systemd service, and upon boot /proc/acpi/wakeup now reports LID0 as disabled. Unfortunately, it still does not work. The computer fails to wake up in most cases. I also tried to disable the USB devices from waking up the device as well, but without any success.

Still the only fix for me is returning to 4.15.0-34...

[Magnus Breder Birkenes (magnusbb)]

I think I just found a solution! I just saw the following bug report over at Redhat (https://bugzilla.redhat.com/show_bug.cgi?id=1597481) and this kernel.org report (https://bugzilla.kernel.org/show_bug.cgi?id=200455).

The bug seems to be related to recent changes in the module related to the Intel Management Engine:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=257355a44b9929e55d6fd47bfff66971dc4de948

I can confirm that blacklisting the mei_me module seems to resolve the issue for my part!

[Nadi (nadi-bar)]

Hei Magnus,
Yes it solved my problem as well. Using kernel 4.19.11, I blacklisted mei_me as you pointed out, now I have no crash when resuming from sleep S3, finally!!
Thanks a lot,
God Jul! :-)

[Magnus Breder Birkenes (magnusbb)]

Everyone affected by this bug, please try 4.15.0-43. This fixes the issue completely for me (without needing to blacklist mei).

This seems to have been the culprit:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803942

System randomly hangs during suspend when mei_wdt is loaded (LP: #1803942)
     - SAUCE: base/dd: limit release function changes to vfio driver only

@ Nadi: God jul!

[Felipe Costa (fsc7)]

I am having this issue now with kernel 4.15.0-44-generic in a Dell Latitude E7440. Ubuntu 18.04

[Nadi (nadi-bar)]

Felipe,
can you try to cancel the lid option? you do it with
sudo sh -c "echo LID0 disabled > /proc/acpi/wakeup"
than check it is '*disabled' in the LID0 entry, by running
cat /proc/acpi/wakeup
and check the output.

You can close the lid and it will sleep, but it will not wakeup when you open the lid, only when you press the power button to start it.
Let me know if it works for you.

[MaskedDriver (maskeddriver)]

I'm having the same issues today after upgrading to 4.15.0.44-generic on a Dell Latitude 5289 Ubuntu 18.04.1

[Magnus Breder Birkenes (magnusbb)]

@MaskedDriver: Does blacklisting the mei_me module (Intel Management Engine) fix the issue? That fixed the problem some weeks ago, perhaps the bug has re-appeared. I have not upgraded to .44 yet...

[debasish ray chawdhuri (debasish-raychawdhuri)]

I have the same problem. Suspend works fine with any kernel version4.14.x, does not work with any version from 4.15.x. I have blacklisted the mei modules, it did not solve the problem. Following are my lsmod.

debashishc@DebashishC-ublp:~$ lsmod
Module Size Used by
btrfs 1343488 0
zstd_compress 188416 1 btrfs
xor 24576 1 btrfs
raid6_pq 122880 1 btrfs
ufs 86016 0
qnx4 16384 0
hfsplus 122880 0
hfs 69632 0
minix 40960 0
ntfs 110592 0
msdos 20480 0
jfs 217088 0
xfs 1441792 0
libcrc32c 16384 1 xfs
cpuid 16384 0
rfcomm 86016 16
ccm 20480 6
cmac 16384 1
bnep 24576 2
arc4 16384 2
uvcvideo 102400 0
videobuf2_vmalloc 16384 1 uvcvideo
videobuf2_memops 16384 1 videobuf2_vmalloc
videobuf2_v4l2 28672 1 uvcvideo
videobuf2_core 45056 2 videobuf2_v4l2,uvcvideo
btusb 53248 0
btrtl 16384 1 btusb
btbcm 16384 1 btusb
videodev 208896 3 videobuf2_core,videobuf2_v4l2,uvcvideo
btintel 16384 1 btusb
media 45056 2 videodev,uvcvideo
bluetooth 626688 52 btrtl,btintel,btbcm,bnep,btusb,rfcomm
ecdh_generic 24576 1 bluetooth
joydev 24576 0
hid_multitouch 24576 0
snd_hda_codec_hdmi 61440 1
snd_hda_codec_realtek 110592 1
snd_hda_codec_generic 86016 1 snd_hda_codec_realtek
snd_soc_skl 98304 0
snd_soc_skl_ipc 73728 1 snd_soc_skl
snd_soc_sst_ipc 16384 1 snd_soc_skl_ipc
snd_soc_sst_dsp 36864 1 snd_soc_skl_ipc
snd_hda_ext_core 28672 1 snd_soc_skl
snd_soc_sst_match 16384 1 snd_soc_skl
snd_soc_core 266240 1 snd_soc_skl
snd_compress 24576 1 snd_soc_core
ac97_bus 16384 1 snd_soc_core
snd_pcm_dmaengine 16384 1 snd_soc_core
ath10k_pci 53248 0
ath10k_core 417792 1 ath10k_pci
ath 32768 1 ath10k_core
mac80211 925696 1 ath10k_core
cfg80211 733184 3 ath,mac80211,ath10k_core
rtsx_pci_ms 20480 0
memstick 16384 1 rtsx_pci_ms
wmi_bmof 16384 0
dell_wmi 16384 0
dell_rbtn 16384 0
dell_laptop 24576 1
dell_smbios 16384 2 dell_wmi,dell_laptop
dcdbas 16384 1 dell_smbios
dell_smm_hwmon 16384 0
binfmt_misc 20480 1
nls_iso8859_1 16384 1
intel_rapl 24576 0
x86_pkg_temp_thermal 16384 0
intel_powerclamp 16384 0
snd_hda_intel 45056 8
coretemp 16384 0
snd_hda_codec 151552 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
kvm_intel 241664 0
snd_hda_core 90112 7 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_h...

[Beniamin Bronisz (beniaminb)]

I have the same issue.
Unfortunately it's now Ubuntu 20.04 and kernel 5.4.0 and it still happens.
My laptop is Lenovo Thinkpad T440p.
First issue that was happening all the time was that the touchpad didn't work after waking from suspend. But it was better known issue with some fixes with the help of some scripts.
This is harder as it's now happening always but only sometimes and I haven't figured out robust steps to reproduce this issue. It just happens sporadically but when it happens only hard reset helps.
My laptop has also Intel CPU and nVidia graphics card so that's something that is common I suppose.
If anything else is needed I could provide more information.