power management - can't wake from sleep mode

"Adam" wrote in message
...

"stepore" wrote in message
...
On 10/02/2015 10:30 AM, Adam wrote:
snip... /and so should you!/

Then, I suspend the desktop causing ping to stop generating info on the
laptop.

Wait, what? I must have missed this in the details, but you're looking to
suspend a desktop? Why?


For "automatic" energy efficiency. Screensaver Preferences has
Power Management settings that I would like to take advantage of to
save energy costs without having to manually shutdown the system,
which is not good for the system.



Pressing CtrlAltF1 on the suspended system caused
ping to continue generating info on the laptop again.

Seems like the system was able to resume but not the display subsystem.

Right, so as I suggested before (and so it seems from another post of
yours) it appears that your graphics drivers are not installed/configured
properly. Reinstall the proprietary drivers (best from AMD directly as
instructed) or try the radeon driver (unless that's what you're actually
using now). Have you even checked to see which driver is loaded?

something like:
lspci -nnk | grep -i vga -A3 | grep 'in use'


Thanks, entering that command gives...

Kernel driver in use: fglrx _pci


adam@ASUS-DESKTOP:~$ lspci -nnk | grep -i vga -A3 | grep 'in use'
Kernel driver in use: fglrx_pci
adam@ASUS-DESKTOP:~$ jockey-text -l
kmod:k10temp - AMD K10 core temperature monitor (Free, Enabled, In use)
xorg:fglrx - ATI/AMD proprietary FGLRX graphics driver (Proprietary,
Enabled, In use)
adam@ASUS-DESKTOP:~$


fglrx may be from PPA Ubuntu-x-swat. But, how to know for sure?

"Henry Crun" wrote in message
...
On 03/10/15 23:59, Adam wrote:

For "automatic" energy efficiency. Screensaver Preferences has
Power Management settings that I would like to take advantage of to
save energy costs without having to "manually" shutdown the system,
which is not good for the system.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why would that be?


You got me.

Er, because, too often, I'll forget to
"manually" shutdown the system. :-)



--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this
message.
Recommended reading:
http://www.catb.org/~esr/faqs/smart-...ns.html#before


--- news://freenews.netfront.net/ - complaints: ---

On 10/03/2015 04:39 PM, Robert Redelmeier wrote:

I have no idea why you might want REI as well.

maybe for the camping trip he takes after torching his box?

(google REI)

On Sat, Oct 03 2015, Robert Redelmeier wrote:

In alt.comp.hardware.pc-homebuilt Robert Marshall wrote in part:
On Sat, Oct 03 2015, DecadentLinuxUserNumeroUno wrote:
There was a thread here (the ubuntu group) a while ago about a key
sequence which restarts a supposedly locked up system.

It utilizes the system request key (SysRq)

Perhaps that person could repost the procedure for you, as I was
unable to find the thread.

ALT-SysRq rseiub (something about Skinny Elephants being Utterly Boring) I
tried that too but will check next time whether sysrq is enabled
/proc/sys/kernel/sysrq suggests it is..

This looks interesting when logged in via ssh
https://en.wikipedia.org/wiki/Magic_..._Magic_Sys Rq
ie echo $SYSRQLetter /proc/sysrq-trigger

I see that page prefers reisub


In X on my Ubuntu-derived system, it takes CTLALTSYSREQ
to be held down while hitting the Magic SysRq commands.
sync is generally safe, and shows in `dmesg`


On my system the Ctrl is not needed - having just tried suspending again
it would appear that the SysRq keys do work, maybe last time I tried it
after running reboot (from ssh) and by the time I invoked SysRq the
system was in some weird half suspended state (see below)?

Looking at syslog below (mildly edited the only removal of entries is
when the ... line occurs, no lines elided between 08:34:25 and 11:20:26)
around the suspend/restart point, 08:34 is when I ran sleep and tried to
wake it at 11:20 but at 11:20:34

11:20:34 systemd[1]: Started Suspend.

!! It would appear to be in a suspend loop? Though I was still able to
login via ssh. I've checked the behaviour for pressing the power
button (which is how I wake it up) and that has 'When power button
pressed - Prompt logout dialogue' I don't think that would be acted
upon once the wake has happened?

The ACPI entry [231373.004566]
ACPI: Preparing to enter system sleep state S3
also looks wrong

Still I'm unsure whether my issues are identical to Adam's he's seeing
his with the flgrx driver I have the extra nvidia driver

08:34:25 kernel: [231371.541636] PM: Syncing filesystems ... done.
08:34:25 kernel: [231371.948124] PM: Preparing system for mem sleep
08:34:25 org.kde.kded5[1784]: powerdevil: ACTIVE SESSION PATH CHANGED: "/"
11:20:26 kernel: [231372.140067] Freezing user space processes ... (elapsed 0.040 seconds) done.
11:20:26 kernel: [231372.180586] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
11:20:26 kernel: [231372.181820] PM: Entering mem sleep
11:20:26 kernel: [231372.181864] Suspending console(s) (use no_console_suspend to debug)
11:20:26 kernel: [231372.182617] parport_pc 00:04: disabled
11:20:26 kernel: [231372.182844] serial 00:03: disabled
11:20:26 kernel: [231372.183069] serial 00:02: disabled
11:20:26 kernel: [231372.183182] sd 2:0:1:0: [sdb] Synchronizing SCSI cache
11:20:26 kernel: [231372.183199] sd 2:0:0:0: [sda] Synchronizing SCSI cache
11:20:26 kernel: [231372.319707] sd 2:0:1:0: [sdb] Stopping disk
11:20:26 kernel: [231372.319855] sd 2:0:0:0: [sda] Stopping disk
11:20:26 kernel: [231372.988038] PM: suspend of devices complete after 805.925 msecs
11:20:26 kernel: [231372.988395] PM: late suspend of devices complete after 0.354 msecs
11:20:26 kernel: [231372.988684] ehci-pci 0000:00:1d.7: System wakeup enabled by ACPI
11:20:26 kernel: [231372.988741] uhci_hcd 0000:00:1d.3: System wakeup enabled by ACPI
11:20:26 kernel: [231372.988758] uhci_hcd 0000:00:1d.2: System wakeup enabled by ACPI
11:20:26 kernel: [231372.988784] uhci_hcd 0000:00:1d.1: System wakeup enabled by ACPI
11:20:26 kernel: [231372.988797] uhci_hcd 0000:00:1d.0: System wakeup enabled by ACPI
11:20:26 kernel: [231372.988922] r8169 0000:03:00.0: System wakeup enabled by ACPI
11:20:26 kernel: [231373.004107] PM: noirq suspend of devices complete after 15.708 msecs
11:20:26 kernel: [231373.004566] ACPI: Preparing to enter system sleep state S3
11:20:26 kernel: [231373.005820] PM: Saving platform NVS memory
11:20:26 kernel: [231373.006059] Disabling non-boot CPUs ...
11:20:26 kernel: [231373.007273] kvm: disabling virtualization on CPU1
11:20:26 kernel: [231373.007282] smpboot: CPU 1 is now offline
11:20:26 kernel: [231373.007451] ACPI: Low-level resume complete
11:20:26 kernel: [231373.007451] PM: Restoring platform NVS memory
11:20:26 kernel: [231373.007451] Enabling non-boot CPUs ...
11:20:26 kernel: [231373.007451] x86: Booting SMP configuration:
11:20:26 kernel: [231373.007451] smpboot: Booting Node 0 Processor 1 APIC 0x1
11:20:26 kernel: [231373.007279] Initializing CPU#1
11:20:26 kernel: [231373.007279] kvm: enabling virtualization on CPU1
11:20:26 kernel: [231373.021154] CPU1 is up
11:20:26 kernel: [231373.022274] ACPI: Waking up from system sleep state S3
11:20:26 kernel: [231373.023163] uhci_hcd 0000:00:1d.0: System wakeup disabled by ACPI
......
11:20:34 systemd[1]: Time has been changed
11:20:34 systemd-sleep[26132]: System resumed.
11:20:34 systemd[1]: Started Suspend.
11:20:34 systemd[1]: Unit sleep.target is not needed anymore. Stopping.
11:20:34 systemd[1]: Stopped target Sleep.
11:20:34 systemd[1]: Stopping Sleep.
11:20:34 systemd[1]: Reached target Suspend.
11:20:34 systemd[1]: Unit suspend.target is bound to inactive unit systemd-suspend.service. Stopping, too.
11:20:34 systemd[1]: Starting Suspend.
11:20:34 anacron[26218]: Anacron 2.3 started on 2015-10-04
11:20:34 anacron[26218]: Normal exit (0 jobs run)
11:20:34 org.kde.kded5[1784]: powerdevil: Switched to inactive session - leaving unchanged
11:20:34 NetworkManager[739]: info wake requested (sleeping: yes enabled: yes)
11:20:34 NetworkManager[739]: info waking up...
11:20:34 NetworkManager[739]: info (eth0): device state change: activated - unmanaged (reason 'sleeping') [100 10 37]
11:20:34 NetworkManager[739]: info (eth0): deactivating device (reason 'sleeping') [37]
11:20:34 NetworkManager[739]: info (eth0): canceled DHCP transaction, DHCP client pid 969
11:20:34 NetworkManager[739]: info Writing DNS information to /sbin/resolvconf
11:20:35 avahi-daemon[787]: Withdrawing address record for fe80::d227:88ff:fe41:eff9 on eth0.
11:20:35 avahi-daemon[787]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::d227:88ff:fe41:eff9.
11:20:35 avahi-daemon[787]: Interface eth0.IPv6 no longer relevant for mDNS.
11:20:35 dnsmasq[984]: setting upstream servers from DBus
11:20:35 avahi-daemon[787]: Withdrawing address record for 192.168.0.14 on eth0.
11:20:35 avahi-daemon[787]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.14.
11:20:35 avahi-daemon[787]: Interface eth0.IPv4 no longer relevant for mDNS.


I see this thread
http://ubuntuforums.org/showthread.php?t=2184159

though that's from a few versions back and relates to closing the lid -
the above syslog entries are from a desktop where I invoked sleep from
the kubuntu main menu

Robert
--
Robert Marshall twitter: @rajm

On Sun, 4 Oct 2015 00:08:48 -0700
"jeff g." wrote:

(google REI)

Have you done that? It really doesn't result in a lot of help.

Googling for, "linux rei," otoh...

Cybe R. Wizard
--
Nice computers don't go down.
Larry Niven, Steven Barnes
"The Barsoom Project"