Red Hat Bugzilla – Bug 1317235
Laptop frozen after suspend (XPS 13 9343)
Last modified: 2016-09-23 15:01:10 EDT
Description of problem:
When closing the lid to suspend my laptop, resuming does not work about 20% of the time. The laptop is then frozen and I have to switch it of (pressing the power button a longer time).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Close lid. Laptop suspends.
2. Open lid. Laptop resumes.
Often fails in step 2: Laptop does not resume. Has to be powered off and booted again.
I think it is related to kernel 4.4.
I think the issue reproduces more often, when the suspended phase is longer (several hours).
Vendor: Dell Inc.
Product Name: XPS 13 9343
Setting severity to high, because of data loss (Laptop has to be powered off).
After several days with kernel-4.3.5 the problem did not reoccur. I'm pretty sure that kernel-4.4 is the problem.
Nobody else experiencing this problem?
You're not the only one getting this issue - I am too. Resume is failing. In some instances (gnome terminal via sudo systemctl suspend) I am able to see the screen as it was pre-suspend, but not do anything.
Arch have this reported as a potential issue on their wiki: https://wiki.archlinux.org/index.php/Dell_XPS_13_(2015)#Graphical_artifacting.2Finstability_after_S3_resume . Suspend/resume is also mentioned here: https://www.ophion.ch/nix/linux-on-a-dell-xps-13-2015-model-9343/ as potentially X server related.
I haven't tried the suggested fix from Arch, but several experiments seem to indicate that switching to a tty first does mean the laptop recovers from suspend quite well. I will try Arch's solution later.
I think this might be Xorg, rather than kernel, related. Another thing to try: enable your ssh daemon:
sudo systemctl start ssh
obviously before you suspend, then ssh into the machine from a remote box. If you're able to do this the kernel is (naturally) fine :) You should then be able to restart your graphical session. If you can't (and you know ssh is configured correctly), the kernel is the issue.
Please disable Audio in BIOS and work with the latest 4.5 kernel from F23-stable. I didn't have any problems in over a dozen suspend tries.
For the SSH thing:
No luck. Either it is the kernel or the network is down to fast. If I find time, I will try with a USB-LAN adapter and configure it statically (not over Gnome/NetworkManager).
Although with the "BIOS No Audio" setup I currently run, I was able to capture the following messages:
>> This was also there before the problems...
[ 110.595820] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
[ 119.616535] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
>> This I never saw before:
[ 120.118795] ACPI Error: Cannot release Mutex [PATM], not acquired (20160108/exmutex-393)
[ 120.118807] ACPI Error: Method parse/execution failed [\_SB.PCI0.LPCB.ECDV._Q66] (Node ffff8802168c2e10), AE_AML_MUTEX_NOT_ACQUIRED (20160108/psparse-542)
Also affects a fresh Fedora Workstation 24 installation, therefore changing Version.
I found this Dell page from 2015: del.ly/6011B6k4l
Same error pattern, but quite old. They say it is patched by Canonical. See also https://bartongeorge.net/2015/08/28/recent-fixes-for-xps-13-developer-edition/ (point 2).
Created attachment 1180009 [details]
Dell Latitude D430 lspci
Created attachment 1180010 [details]
Dell Latitude D430 lsmod
Exact thing happens to my Dell Latitude D430 100% of the time. It enters suspend correctly, but on leaving suspend I get a frozen desktop screen. The system is so badly frozen that using does nothing.
Sorry, that using the caps lock has no effect.
Created attachment 1180012 [details]
Dell Latitude D430 dmesg
I was able to coax an ABRT report after the update to Kernel 4.6.4-301.
I filed the report here: bug 1358546
also see bug 1358555
After the latest Kernel update I no longer have problems.
Closing this bug as fixed. If this is not correct please reopen.