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): 4.4.4-301.fc23.x86_64 How reproducible: Often Steps to Reproduce: 1. Close lid. Laptop suspends. 2. Open lid. Laptop resumes. Actual results: Often fails in step 2: Laptop does not resume. Has to be powered off and booted again. Expected results: works. Additional info: 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. Version: A07 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.
@Antony, others: 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 -Dave
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.