Suspend does not always resume

Bug #1757445 reported by Jamie Bennett on 2018-03-21
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned
Bionic
Medium
Unassigned
linux-meta-hwe (Ubuntu)
Undecided
Unassigned

Bug Description

Dell XPS 13 9350 on AC power left running overnight, suspends after a given timeout. When coming back the next morning sometimes the laptop resumes to an aubergine desktop (just the screen, no GDM) and cursor and sits there forever. Sometimes it resumes to a black screen and cursor.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-12-generic 4.15.0-12.13
ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
Uname: Linux 4.15.0-12-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Mar 21 14:15:04 2018
InstallationDate: Installed on 2018-02-13 (36 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180201)
MachineType: Dell Inc. XPS 13 9350
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-12-generic root=UUID=bc5b647b-38ca-4206-9e96-774a5ac6b833 ro quiet splash vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-12-generic N/A
 linux-backports-modules-4.15.0-12-generic N/A
 linux-firmware 1.173
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/18/2017
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.5.1
dmi.board.name: 07TYC2
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.5.1:bd08/18/2017:svnDellInc.:pnXPS139350:pvr:rvnDellInc.:rn07TYC2:rvrA01:cvnDellInc.:ct9:cvr:
dmi.product.family: NULL
dmi.product.name: XPS 13 9350
dmi.sys.vendor: Dell Inc.

Jamie Bennett (jamiebennett) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Will Cooke (willcooke) wrote :

I'm seeing messages in syslog that show USB device(s) not reconnecting. I spoke to Jamie and his monitor is connected over a USB-C dock. That might be involved here.

Joseph Salisbury (jsalisbury) wrote :

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.16 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.16-rc6

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: kernel-da-key
Thomas Reuss (thomas-reuss) wrote :

Similar problem over here, resume reproducibly fails on my Dell Mini 1018:
STR seems to work properly when closing the lid:
Blanked screen, pulsating power led etc. When I try to wake up the system, the power LED would switch on, however the screen stays black.

Same fault with Dell Inspiron 5557. On resume it takes about 4 seconds and then the lock screen appears, when trying to unlock it accepts four to five digits and then hangs completely (nor REISUB works). The only option is manually power off.

After some tests I discovered that, in my case, the locking is related to wireless. By disabling the wireless network the problem disappears, it suspends and returns normally.
So, as a test, I deactivated the power saving, as suggested in the link "https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55" and everything went smoothly.

Please disregard comment # 7, I celebrated too early. After some time the problem returned.
I am currently testing the 4.16 kernel (0). In a few days I will post some results.

I have been testing the Kernel 4.16.0 for two days, so far suspend and resume has been working without hanging
However, whenever I suspend and resume, at least once, when I try to shut down the system hangs and only accepts REISUB or forced shutdown.
Besides that, I lost the functionality of ureadahead, which does not work with "upstream kernels".

I noticed the existence of this error during the boot: "nouveau 0000: 01: 00.0: bus: MMIO read of 00000000 FAULT at 612004 [IBUS]".
So I decided to search and found a suggestion to include the following parameter in the kernel command line "nouveau.modeset = 0". So I decided to test it and immediately the boot errors disappeared, there were no more crashes when suspending and resuming, just as there were no more crashes when shutting down. Either with the 4.16-0 kernel nor with the official 4.15.0-20 kernel.
I suggest to those affected by this bug that they try this suggestion.

EDIT: "nouveau.modeset=0" no spaces.

Eugene San (eugenesan) on 2018-07-18
tags: added: xenial
tags: added: linux-hwe
Eugene San (eugenesan) wrote :

The bug also affects Xenial with Linux HWE (4.15.0.24.46).
No issues with Linux HWE (4.13.0.45.64).

no longer affects: linux-meta-hwe (Ubuntu Bionic)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-meta-hwe (Ubuntu):
status: New → Confirmed
sauron (pierre-zechateau) wrote :

Hi there, I'm running the kernel 4.15.0-34-generic #37 on an ASUS N752VX with the same problem too :
Blanked screen and pulsating power led.
When I try to wake up the system, the power LED would switch on, fans starts however the screen stays black. I've plugged an external screen, without result. I have to hard reboot each time.

Eugene San (eugenesan) wrote :

Just wanted to share my observations.

At least on my machine, "failed resumes" are appearing in series after initial BSOD (black screen of death), which usually occurs after a long suspend.

After some experimentation, I've found that full/proper shut-down and boot-up cycle (in addition to the forced power-down after the initial BSOD) fixes the issue until next BSOD occurs.

My guess is something in kernel 4.15.xx triggers the BSOD and messes suspend-resume parameters in EFI until it's re-set by the procedure mentioned above.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers