[Dell Dimension E521] System goes to sleep at GDM window and never wakes up

[John Relph]

On my Dell Dimension E521, a desktop system, if I leave the system at the login prompt it will very quickly go to sleep. When I press the power button to wake it, the system seems to restart, but the screen and the keyboard never wake up. I have to poke it in the eye and reboot.

This behavior effectively renders the machine unusable if I am away. If the power goes out and the system reboots, it will very quickly sleep and never wake up. Thus, I cannot use it remotely.

And if I forget to immediately (IMMEDIATELY) log in, the system will go to sleep and I have to hard power off and reboot. Very annoying.

This only happened once I upgraded to 14.04.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-27-generic 3.13.0-27.50
ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11
Uname: Linux 3.13.0-27-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: relph 3132 F.... pulseaudio
CurrentDesktop: KDE
Date: Thu Jun 5 07:25:56 2014
HibernationDevice: RESUME=UUID=4910abff-aedb-49ea-a640-881c159d9639
IwConfig:
 eth0 no wireless extensions.

 eth1 no wireless extensions.

 lo no wireless extensions.
MachineType: Dell Inc Dimension E521
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-27-generic root=UUID=449c36fa-de2d-44cf-ad97-450c0903f337 ro quiet splash nomdmonddf nomdmonisw
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-27-generic N/A
 linux-backports-modules-3.13.0-27-generic N/A
 linux-firmware 1.127.2
RfKill:

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

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.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.15 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'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-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/v3.15-rc8-utopic/

[penalvch (penalvch)]

John Relph, could you please provide the missing information 3) and 4) following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[John Relph (relph)]

It was a real pain to install the latest mainline rc kernel. I had to uninstall my nvidia driver, and then the system couldn't bring up X correctly. Even switching to the text console was painful, because the system would hang periodically. So I couldn't bring up a browser to follow the DebuggingKernelSuspend instructions. I will try again, but it probably won't be until tomorrow.

[John Relph (relph)]

While booted into the latest non-daily mainline kernel, please attach to your report:

cat /proc/acpi/wakeup > wakeup

[John Relph (relph)]

4. While booted into the latest non-daily mainline kernel, please attach to your report the resume trace mentioned below.

[penalvch (penalvch)]

John Relph, the latest non-daily mainline kernel is http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc8-utopic/ .

[John Relph (relph)]

4) dmesg > dmesg.txt

Attempt #2.

[John Relph (relph)]

3) cat /proc/acpi/wakeup > wakeup

Attempt #2.

[penalvch (penalvch)]

John Relph, the next step is to fully commit bisect the kernel in order to identify the offending commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

[John Relph (relph)]

I did it wrong last time, do you have more specific instructions?

By the way, I seem to remember I didn't have this problem in 13.10.

[John Relph (relph)]

I'm sorry, I'm reading the kernel bisect page, and I really have no idea where to start. I thought I did, so I attempted to clone the repository thus: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-saucy.git

but that gives an error:

Cloning into 'ubuntu-saucy'...
fatal: remote error: access denied or repository not exported: /ubuntu/ubuntu-saucy.git

I asked for help, and I'm asking again.

[penalvch (penalvch)]

John Relph, one must use the git clone URL noted from the appropriate repository found at http://kernel.ubuntu.com/git .

[John Relph (relph)]

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

[John Relph (relph)]

On a related note, perhaps, a power surge seems to have fried my GFX board (or perhaps the PCIe slot itself), so I am reduced to using the motherboard bog standard VGA. The problem still occurs. That is, the system boots and then, after about a minute, goes to sleep. Never to wake up. Still no video on the VGA after attempting to wake the system.

[John Relph (relph)]

See also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1326759

[John Relph (relph)]

I am unable to commit bisect the kernel because I can't even get the system to boot with any of the older kernels.

The bug is still happening, which is to say that the system boots to the login prompt, then after a minute or so goes immediately to sleep (hibernate?). When I press the power button to wake the system, the keyboard and monitor are dead and the system never comes back awake. I have to hold down the power button to kill the system, and then reboot from scratch. Once the system comes back up (after doing fsck etc.) and I log in (because if I don't, I get to start the entire process all over again), I get error dialogs saying there was a problem with Ubuntu.

Well, duh, I knew that.

If you have any hints on how to get my system to come up with the older kernels, please offer them now. If you have a fix for this bug, please offer it now.

Otherwise, I know not how to help isolate the problem. Aside from buying a different system, which is silly. This one (mostly) works. Aside from two really annoying Ubuntu bugs.

[penalvch (penalvch)]

John Relph, let us put the bisect on hold for now, given how bisecting would be prohibitive. Hence, could you please test the latest mainline kernel via http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-rc5-utopic/ and advise to the results?

[John Relph (relph)]

I installed the following:

linux-headers-3.17.0-031700rc5_3.17.0-031700rc5.201409151105_all.deb
linux-headers-3.17.0-031700rc5-generic_3.17.0-031700rc5.201409151105_amd64.deb
linux-image-3.17.0-031700rc5-generic_3.17.0-031700rc5.201409151105_amd64.deb

The system seemed to boot fine, then after about a minute at the login prompt it went to sleep. I pressed the button (once it had quiesced) to wake it up, and it got very unhappy. The fan started whirring at max, the display was still dead and the keyboard did not respond. After a minute of the machine howling in despair, I poked it in the eye and booted the known good kernel.

(Currently running 3.13.0-36-generic #63, which also goes to sleep if I don't log in at the GDM window within a minute.)

[penalvch (penalvch)]

John Relph, could you please test the latest mainline kernel via http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-rc6-utopic/ and advise to the results?

[John Relph (relph)]

Same result as with http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-rc5-utopic/
That is, it's still broken and my CPU still goes nuts when failing to reawake.

[penalvch (penalvch)]

John Relph, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel 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)]

Arf. The problem exists in this kernel. There are two bugs, I've reported them both, and neither has been fixed. Is this a new bug? What makes you say so? I don't understand.

The issue is not the CPU winding up to the speed of sound, though that certainly is, um, interesting.

The issue is that, first, the system goes to sleep if I don't login immediately after boot, and, second, that if I attempt to wake up the system that is sleeping, which it shouldn't be doing in the first place, it doesn't ever wake up. The system should not go to sleep, ever. And it does. That's a bug. And that's really the only bug I care about. I don't want my system to go to sleep. Hibernate. Snooze. Whatever. I told it not to. And it does, over my desperate and useless protests. The fact that it doesn't wake up is a bummer, but since it should never have gone to sleep in the first place, it's really just an annoying side effect of the first problem.

What is it to me if it acts out while failing to wake up?

Still, if you insist...

[John Relph (relph)]

By the way, what driver maintainer list am I supposed to send to?

And I quote:

------------
Reporting non-USB bugs upstream

If the bug is not in USB, the first step in reporting a bug upstream is to find the maintainer of the driver for the bug from the MAINTAINERS list, or if a kernel graphics issue http://www.x.org/wiki/XorgMailingLists/. Then, using the Kernel.org format, please:
Send an E-Mail to the mailing list indicated by the 'L:' (use the maintainer E-Mail ONLY if no list is specified).
If this is a regression, CC the submitter of the regression commit, and the maintainer. Also, CC those who have made recent (6 months to a year) changes to the module you are reporting about.
------------

I don't know what driver to pick from the list.

[penalvch (penalvch)]

John Relph, please send this to the linux-acpi mailinglist.