System sleeps at GDM prompt even when told not to

[John Relph]

After upgrading to 14.04, my Dell Dimension E521 sleeps at the GDM login window after a short amount of time. But I have used the System Settings -> Power Management -> Energy Saving panel to tell it never to Suspend Session. I have Screen Energy Saving set to 10 minutes. I have tried many different settings based on recommendations found on the web, but no matter what, the system sleeps at the GDM login window after a short amount of time.

I'm using Kubuntu, running KDE, not that horrible Ubuntu interface for tablet users.

This sleep behavior causes two problems:

1) The system goes to sleep and never wakes up, but that is the subject of a different bug.

2) If the system reboots for any reason, it then promptly goes to sleep, which means that it is essentially down, and then I cannot access it remotely. And I access it remotely quite often. I rely on my system being up and accessible, and this bug prevents me from using the system after it reboots. For example, if the power goes out at my house (which it does). I have the BIOS set to reboot after power loss, but then the system goes to sleep.

So, how do I tell my system NOT to go to sleep while waiting for login at the GDM window? Why do the Power Management settings appear to do nothing at the GDM window? How do I configure the GDM window sleep behavior?

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:35:17 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)
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/

[Joseph Salisbury (jsalisbury)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

  With the recent release of this Ubuntu release, would like to confirm if this bug is still present. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[penalvch (penalvch)]

John Relph, which prior release specifically did this not happen in?

[John Relph (relph)]

It appears that I upgraded from 13.10 to 14.04 on April 19-20.

[penalvch (penalvch)]

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

[John Relph (relph)]

I installed the following from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-rc2-utopic/:

linux-image-3.16.0-031600rc2-generic_3.16.0-031600rc2.201406220135_amd64.deb
linux-headers-3.16.0-031600rc2-generic_3.16.0-031600rc2.201406220135_amd64.deb

The bug exists. My system went to sleep after approximately a minute or so. Didn't wake up correctly. The bug exists.

[penalvch (penalvch)]

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

[John Relph (relph)]

Sorry, I won't be able to get the kernel bisection until perhaps the middle of July but most likely the beginning of August.
I am traveling a lot this summer and won't have more than a week at home until August. And I'm not going to be spending those few days at home bisecting a kernel.

[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

[penalvch (penalvch)]

John Relph, when you were using Saucy, were you using the exact same RAID setup?

[John Relph (relph)]

Yes, absolutely. Didn't change a thing when I did the upgrade. Didn't notice any errors during the upgrade. Everything seems to work fine, except the sleeping and never waking up issue.

[John Relph (relph)]

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

[penalvch (penalvch)]

John Relph, regarding the scope of this report where you configured in KDE System Settings to not suspend, but it does it anyways, this would appear to not be a linux (Ubuntu) kernel issue, but of the settings not persisting at the login prompt. As I'm not sure of the package responsible for this, I'll have to put it in the Ubuntu general queue for reassignment by a specialist.

Regarding the problem of the computer suspending and then not waking back up, and rebooting causing a suspend, while those issues would be properly filed against the linux (Ubuntu) package, as you noted in the Bug Description, these issues would need to be filed separately, each in their own new report. Hence, please feel free to file these via a terminal and subscribe me:
ubuntu-bug linux

Thank you for your understanding.

[John Relph (relph)]

They are exactly the same issue. If the settings persisted at the login prompt, then rebooting would not cause a suspend.

Unless there's some other magick incantation that controls whether or not a system suspends at the login prompt, perhaps somewhere deep inside the bowels of the GDM config. Which I haven't been able to find.

Why don't you just reassign this bug to the general queue?

[penalvch (penalvch)]

John Relph, just to clarify, no they are not considered the same issue at this point. The settings you configured would have nothing to do with suspend not waking back up (kernel issue more than likely) or rebooting causing a suspend (may also be a kernel issue, or it's not actually suspending but hanging when attempting to reboot).