[Dell Dimension E521] Computer hangs when resuming after suspend

[John Relph]

When my computer suspends, it will never fully wake back up.

When I press the power button to resume, the computer appears to start waking up, but the monitor and keyboard are never reactivated and I cannot log in from another system (I have ssh access enabled but the system does not respond). If I wait long enough (5 minutes or so), the system will start gradually screaming, as if it's using max CPU and the fan is responding in kind by cranking up to max. But still, no matter how long I wait (and how much noise is emitted and power consumed), the system never fully resumes after suspend.

I have to push and hold the power button to force power off and then reboot.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-39-generic 3.13.0-39.66
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
Uname: Linux 3.13.0-39-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: relph 3099 F.... pulseaudio
                      relph 3173 F.... kded4
 /dev/snd/controlC0: relph 3099 F.... pulseaudio
                      relph 3173 F.... kded4
Date: Sat Nov 15 09:59:21 2014
HibernationDevice: RESUME=UUID=4910abff-aedb-49ea-a640-881c159d9639
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Dell Inc Dimension E521
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-39-generic root=UUID=449c36fa-de2d-44cf-ad97-450c0903f337 ro quiet splash nomdmonddf nomdmonisw vt.handoff=7
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-39-generic N/A
 linux-backports-modules-3.13.0-39-generic N/A
 linux-firmware 1.127.8
RfKill:

SourcePackage: linux
UpgradeStatus: Upgraded to trusty on 2014-04-20 (209 days ago)
WpaSupplicantLog:

dmi.bios.date: 08/02/2007
dmi.bios.vendor: Dell Inc
dmi.bios.version: 1.1.11
dmi.board.name: 0UW457
dmi.board.vendor: Dell Inc
dmi.board.version: A03
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc
dmi.modalias: dmi:bvnDellInc:bvr1.1.11:bd08/02/2007:svnDellInc:pnDimensionE521:pvr:rvnDellInc:rn0UW457:rvrA03:cvnDellInc:ct3:cvr:
dmi.product.name: Dimension E521
dmi.sys.vendor: Dell Inc

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

John Relph, 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, and please do not test the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to 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-rc4

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.

[John Relph (relph)]

Actually, I'm not sure that the bug really exists in the upstream kernel, because I'm not certain that the upstream kernel successfully suspended. The power button light was still green, and when I pressed it, nothing actually happened.

Should I try some other kernel until I'm absolutely certain that it suspended correctly?

[penalvch (penalvch)]

John Relph, if you attempted to suspend with the 3.18-rc4 kernel, and it didn't do so successfully, that would be enough of a test to verify the same bug in the upstream kernel.

As well, could you please provide the missing information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

Also, did this problem not occur in a release prior to Trusty?

[John Relph (relph)]

This problem did not occur in a release prior to Trusty.

The computer suspended automatically, about 1 minute after boot.

(I don't want it to suspend, but that's the subject of another bug report.)

[penalvch (penalvch)]

John Relph, the next step is to fully commit bisect from the prior release this is not reproducible in 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

[John Relph (relph)]

I don't think I have enough available disk space to do a commit bisect at this time. But I'll give it a shot.

[John Relph (relph)]

By the way, I have a memory of attempting to bisect just the kernels (ignoring the commits) having a bad result. Please refer to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1326757/comments/15 in which I documented bad experiences attempting just such. And I quote:

I have tried installing a number of older kernels in order to attempt to find the last known good or first known bad kernel, following the examples on https://wiki.ubuntu.com/Kernel/KernelBisection in the "Bisecting Ubuntu kernel versions" section. Not one of the kernels I have installed has booted correctly.

I have guessed that the bogus kernel was built between the last good saucy 13.10 kernel I used and the first trusty 14.04 kernel I installed.

First I installed trusty 3.12.0-8.16. It would not boot. I got a full crash.

Then I installed saucy 3.11.0-26.45. It would not boot because MDADM could not find my RAIDs.

So then I tried trusty 3.13.0-4.19. It would not boot, again because MDADM:
Incrementally starting RAID arrays...
mdadm: CREATE group disk not found
Incrementally started RAID arrays.

Is there something I'm doing wrong?

I have been installing all three images as per the wiki page, for example:
linux-headers-3.13.0-4_3.13.0-4.19_all.deb
linux-image-3.13.0-4-generic_3.13.0-4.19_amd64.deb
linux-headers-3.13.0-4-generic_3.13.0-4.19_amd64.deb

[penalvch (penalvch)]

John Relph, just to clarify, what was the most recent release specifically that did not demonstrate this problem?

[John Relph (relph)]

Well, here's the deal. I was running 13.10 and I never had any problem with it. But I did not use suspend nor did I use hibernate. I either had a fully up and running system or I shut it down cold. I never had any reason to want to use suspend or hibernate.

Then I upgraded to 14.04 and immediately I start having two problems, the first being that the system would suspend itself after 1 minute if I did not log in at the GDM prompt, and the second being that if I attempted to awaken the system from suspend it would never wake up (no keyboard, no mouse, no network).

As far as priority goes, I would prefer that the first problem were solved. I would not care in the least that the system would never wake up after suspend if the system wouldn't suspend in the first place. In fact, it's the fact that the system suspends itself even though I don't want it to that is the real source of headache for me. The fact it never wakes up is fixable with a hard power off and reboot and log in immediately upon GDM. The fact it suspends is not fixable, because if the power goes out and I'm not home and it reboots and I don't log in (because I'm not home) then the system suspends and it's not usable from my remote location. Which sucks big green... well, you get the picture.

So when it comes right down to it, I'd rather efforts were put toward figuring out how I can configure my machine not to suspend in the first place. Which is the other bug, not this one.

[penalvch (penalvch)]

John Relph, 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.

[John Relph (relph)]

I'm almost certain I did this already. Nothing ever came of it. I never heard back from anybody.

[John Relph (relph)]

Yes, I did. October 1.
http://comments.gmane.org/gmane.linux.acpi.devel/71159

[Dimitris Menemenlis (dmenemenlis)]

Hi was there ever a resolution or workaround for the "hangs when resuming after suspend" bug for the Dell Dimension E521?

I confirm exactly the same behavior with Lubuntu 14.04. I have tried successive kernels of 14.04, both 32-bit and 64-bit, and they have all failed the same way.

I find that lubuntu 10.04 32-bit suspends and resumes correctly, with one minor easily fixable mouse pointer issue.

Lubuntu 12.04 32-bit from live USB also suspends, but as soon as it is installed on hard disk and kernel is updated, it stops functioning.

(In addition to the "hangs when resuming after suspend" issue, bug 1326757 also addresses the problem of "system goes to sleep at GDM window", so I do not think it is an exact duplicate.)

[Dimitris Menemenlis (dmenemenlis)]

Just to emphasize the last point in above comment, I use lubuntu 14.04 and there is no issue with "system goes to sleep at GDM window".