Dell 5737 freezes on ubuntu14 everytime during resume from suspend

[Tigran]

My dell 5737 laptop was running all fine on 12.04. As soon as I upgraded to 14.04 I am consistenly running into system freeze everytime system attempts to resume from suspend. This happens when I simply close the lit of my laptop or due to screen inactivity suspend... When that happens only thing that works is hard reset. This is 100% reproducible.

Interestingly, I noticed that on 3.11.10 kernel if I suspend manually from menu, the laptop resumes just fine.

I tried pretty much all kernels upward including 12.04 ppa, even upgrading to 14.10 does not help. I am currently running 3.16.0-24-generic kernel. I even upgraded my BIOS to A10 (even though it was clearly stated optional on Dell site).

When I boot using 3.11.10 kernel all is well except my virtualbox no longer functions then.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-24-generic 3.16.0-24.32
ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4
Uname: Linux 3.16.0-24-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: tigran 2677 F.... pulseaudio
 /dev/snd/controlC0: tigran 2677 F.... pulseaudio
CurrentDesktop: Unity
Date: Sat Nov 8 16:55:39 2014
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=13e6d588-5ce1-44fb-ba8a-2c65b9cf8b3d
InstallationDate: Installed on 2014-03-25 (228 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MachineType: Dell Inc. Inspiron 5737
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-24-generic.efi.signed root=UUID=8a7c9255-ff8b-4a86-b586-07d8695f44cc ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-24-generic N/A
 linux-backports-modules-3.16.0-24-generic N/A
 linux-firmware 1.138
SourcePackage: linux
UpgradeStatus: Upgraded to utopic on 2014-10-28 (11 days ago)
dmi.bios.date: 04/30/2014
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A08
dmi.board.name: 04X8RP
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A08
dmi.modalias: dmi:bvnDellInc.:bvrA08:bd04/30/2014:svnDellInc.:pnInspiron5737:pvrA08:rvnDellInc.:rn04X8RP:rvrA00:cvnDellInc.:ct8:cvrA08:
dmi.product.name: Inspiron 5737
dmi.product.version: A08
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Tigran, thank you for reporting this and helping make Ubuntu better. Could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing in your release) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested exactly shown as:
kernel-fixed-upstream-3.18-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Tigran (tigrand)]

Thanks for quick response Chris. I just tested the latest upstream and was able to reproduce the issue by simply closing the lid, wiating for suspend and then reopening the lid. The system completely freezes and hard reset is the only cure. Please, let me know if I can help with anything else

This was the uname report after kernel isntall and reboot to confirm I am running the new kernel:

~$ uname -a
Linux vtdlap1 3.18.0-031800rc3-generic #201411022335 SMP Sun Nov 2 23:36:52 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[penalvch (penalvch)]

Tigran, the next step is to fully commit bisect from Precise to Trusty in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ? Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Tigran (tigrand)]

Hi Chris,

Since the original good and bad versions vary in releases, and as I understood releases split to different git repositories, I thought it will help first if I do kernel release bisect to understand which release went wrong.

So, I used the bisect logic to manually download kernel binaries, install and try till I find the last good kernel release. But kernel versioning confused me a bit at the end and I am hoping you can help me figure it out.

So I started from 3.11.0.23 being the known GOOD version, and 3.13.11.09 being my attempted BAD version.

I used http://kernel.ubuntu.com/~kernel-ppa/mainline/ as the source of binary releases.

Since I didn't clearly understand the versioning I also decided to try the 3.11.10.15 which was also GOOD. From that on, I did a bisect logic between 3.11.10.15 - 3.13.11.09. It turned out these was broken quite long back!

So to summarize my results (at the bottom I am copying the full bisect test details):
LAST known good release: 3.11.10.15 (Here I assumed 3.12.0-rc1 immidiately follows this release, but I can be wrong, see further.).

But then I browsed the following URL and as I understood the trusty rc1 didn't really start on top of 3.11.10.15 but rather was branched off of 3.11.0-12.19. Is this correct? If so, it confuses me a bit now.

Given that 3.11.0-23 is GOOD, I wonder did all the changes from 3.11.0.12-3.11.0.23 also go into trusty (or maybe even vise versa, backported from trusty)?

What should I do next? my last known good version and first known bad version are still split between git repos sounds like.

The full details of my bisect test if will help:
[DIR] v3.11.10.15-saucy/ 25-Aug-2014 09:52 - GOOD
[DIR] v3.12-rc1-saucy/ 16-Sep-2013 22:00 - BAD (Freezes immediately after login)
[DIR] v3.12-rc2-saucy/ 23-Sep-2013 23:54 -
[DIR] v3.12-rc3-saucy/ 29-Sep-2013 22:54 - BAD (Freezes immediately after login)
[DIR] v3.12-rc4-saucy/ 08-Oct-2013 11:58 -
[DIR] v3.12-rc5-saucy/ 14-Oct-2013 00:10 -
[DIR] v3.12-rc6-saucy/ 19-Oct-2013 20:54 - BAD (Freezes immediately after login)
[DIR] v3.12-rc7-saucy/ 27-Oct-2013 23:54 -
[DIR] v3.12-trusty/ 08-Nov-2013 00:01 -
[DIR] v3.12.1-trusty/ 20-Nov-2013 22:18 -
[DIR] v3.12.2-trusty/ 29-Nov-2013 21:03 -
[DIR] v3.12.3-trusty/ 04-Dec-2013 20:17 -
[DIR] v3.12.4-trusty/ 08-Dec-2013 17:35 -
[DIR] v3.12.5-trusty/ 12-Dec-2013 08:19 -
[DIR] v3.12.6-trusty/ 20-Dec-2013 17:55 -
[DIR] v3.12.7-trusty/ 09-Jan-2014 22:30 - BAD
[DIR] v3.12.8-trusty/ 16-Jan-2014 01:17 -
[DIR] v3.12.9-trusty/ 25-Jan-2014 18:21 -
[DIR] v3.12.10-trusty/ 06-Feb-2014 21:35 -
[DIR] v3.12.11-trusty/ 13-Feb-2014 23:37 -
[DIR] v3.12.12-trusty/ 20-Feb-2014 21:13 -
[DIR] v3.12.13-trusty/ 22-Feb-2014 23:22 -
[DIR] v3.12.14-trusty/ 11-Mar-2014 19:04 -
[DIR] v3.12.15-trusty/ 26-Mar-2014 13:20 -
[DIR] v3.12.16-trusty/ 02-Apr-2014 18:21 -
[DIR] v3.12.17-trusty/ 07-Apr-2014 18:21 -
[DIR] v3.12.18-trusty/ 24-Apr-2014 02:19 -
[DIR] v3.12.19-trusty/ 09-May-2014 08:18 -
[DIR] v3.12.20-trusty/ 16-May-2014 14:19 -
[DIR] v3.12.21-trusty/ 02-Jun-2014 23:22 -
...

[Tigran (tigrand)]

I seem to missed pointing which URL I used to realize trusty is not following immediately my know last good release:
https://launchpad.net/ubuntu/trusty/+source/linux

Also one more thing that may help to locate the bug. I noticed that, in whichever release this resume issue exists, I also cannot change the brightness of the laptop.
When I change the laptop the ruler changes, but it makes no affect to the existing brightness. Maybe related...

[penalvch (penalvch)]

Tigran, regarding the following:
[DIR] v3.11.10.15-saucy/ 25-Aug-2014 09:52 - GOOD
[DIR] v3.12-rc1-saucy/ 16-Sep-2013 22:00 - BAD (Freezes immediately after login)

Assuming when you say BAD you mean that you were able to test to the issue and it still reproduces the problem, the next step would be commit bisecting between these two versions.

[Tigran (tigrand)]

Chris, sorry if I wasn't clear, but what I don't quite understand is how to bisect between two different git repositories?

one which is bad is ubuntu-trusty, the other one is ubuntu-saucy.

The way I see it their intersection is 3.11.0-12.19 (that seems to be where trusty branched). So I am trying first to try and build that one and give it a try. Hopefully, the test will let me figure out from that point on which repo to use for bisect. Is this the way you suggest?

>> Assuming when you say BAD you mean that you were able to test to the issue and it still reproduces the problem, the next step >> would be commit bisecting between these two versions.

These versions where I marked (Freezes immidiately after login) do not even allow me to close the lid as they freeze immidiately after login. But it seems to me it's quite likely I am hitting the source issue. I don't know how I can test it up to my issue point though to be sure.

[penalvch (penalvch)]

Tigran, just to clarify, you would switch to bisecting the mainline kernel (one single git repo) as outlined in the article.

However, regarding the BAD results, this would be not BAD but inconclusive. Hence, your bisect would need to be broadened to a known good and known bad testing results, not inconclusive.

[Tigran (tigrand)]

Chris, the best I could reach was I was able to build and confirm 3.11.0-12.19 is good, which is the beginning of trusty. But after that pretty much every release upto 3.12.0-7.15 is "inconclusive".

build 3.12.0-1.3 - inconclusive (immediately freezes after login)
...
build 3.12.0-7.15 - inconclusive (after resume, the black screen stays but seems system is not completely frozen, capslock still reacts).

These "inconclusive"s right after the last good build (3.11.0-12.19) build pretty much force me to stop my progress troubleshooting this bug further as I don't know how to deal with inconclusives.

Please, let me know if I can provide anything else, but I basically gave up on commit bisect part.

[penalvch (penalvch)]

Tigran, could you please provide the missing information using 3.18-rc4 (or the Ubuntu kernel if this is also inconclusive) following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[Tigran (tigrand)]

Chris, apologies for delay. Just tried the latest availabe build 3.18-rc6 and, like rc3 build that I tried, the issue is 100% reproducible. As soon as I open the lid to resume from suspend, the login screen comes up and the system freezes.

[Tigran (tigrand)]

Also note that I followed the instructions in https://wiki.ubuntu.com/DebuggingKernelSuspend to manually suspend and trace the suspend-resume. But after suspend when I powered up to resume the laptop successfully resumed.

As I noted earlier, if I suspend the laptop manually via System menu, most of the time I can then successfully resume it. But if I close the lid and let the laptop suspend by configured action I can reproduce the issue consistently 100%.

[penalvch (penalvch)]

Tigran, would there be a kernel call trace you could attach uncompressed/untarred following https://help.ubuntu.com/community/DebuggingSystemCrash ?

[Tigran (tigrand)]

Chris, I just tried the following:

Unlike the KernelSuspend, this time I tried to start the trace, but suspend not via pm-suspend but via closing the lid.

- sudo sh -c "sync && echo 1 > /sys/power/pm_trace
- closed lid
- once system suspended opend the lid
- system frozen. Hard-reset by prressing and holding the power button
- on reboot system appeared to catch fsck which I canceled (good sign RTC is tampered).
- loged-in and captured the dmesg log (see attached as dmesg3.txt)

:~$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled
LID0 S3 *enabled platform:PNP0C0D:00
EHC1 S0 *enabled pci:0000:00:1d.0
XHC S0 *enabled pci:0000:00:14.0
PXSX S4 *disabled
RP03 S3 *disabled pci:0000:00:1c.0
PEG0 S4 *disabled
PEGP S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled

[Tigran (tigrand)]

Not sure if this tells anything, but since I was not able to track any "hash matches" string in dmesg3.txt that follows the

[ 1.958820] hash matches /home/apw/COD/linux/drivers/base/power/main.c:814

As per notes in s2ram.txt, I executed the following:

~$ cat /sys/power/pm_trace_dev_match
bdi

Hopefully it gives some clue

[penalvch (penalvch)]

Tigran, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (linux-acpi) by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.

[Tigran (tigrand)]

Unfortunately, I was quite busy and didn't actually report the problem to upstream kernel yet... But here is an update hoping this may help someone who experiences the same problem to save some time

As I further noticed, freezes happend not only during resume but also sometimes due to inactivity display lock, or sometimes when I was just pressing the suspend menu item (before actually suspend happens). So I assumed something else might be going on other than the resume. Since my brightness didn't work either, my first focus went to it.

I noticed I have two independent modules that attempt to manage the brightness: intel_backlight and dell_backlight. I also noticed that echoing different values into /sys/class/backlight/dell_backlight had no effect, so I balcklisted dell_laptop module in /etc/modprobe.d/blacklist.conf, and after reboot can no longer reproduce my issue.
Hope this is it and I got to the source...

My understanding is dell_laptop module was conflicting and causing the actual freeze.

[vincent trekels (vincent-trekels)]

Tigran,

i am a new ubuntu (linux) user i ran in to the same problems as you and sinds this form seems like the only one giving a solution i want to give it a shot , but what do you mean exactly by 'blacklisted' ?

thanks
vincent

[Mihhail Afanasjev (moshanator)]

Blacklisting dell_laptop fixed the issue for me as well.
Vincent, here's how to do it: open terminal, type:
echo "blacklist dell_laptop" | sudo tee -a /etc/modprobe.d/blacklist.conf
This command appends the words "blacklist dell_laptop" to the "blacklist.conf" file. The dell_laptop driver will not be loaded on startup and will not cause the freeze anymore.

[vincent trekels (vincent-trekels)]

Mihhail,

thanks a lot it worked , now i can finally ditch my windows os :).