I have been watching this forum item https://forums.opensuse.org/showthread.php/507423-Suspend-Hibernate and it may be related to my issue, but decided to start a clean thread.
I have 13.2/KDE 4.14.6 running on an AMD A8 CPU, running fglrx video driver interfacing dual 1920x1080 displays.
After upgrade to 13.2 (from 13.1), the radeon driver would not start up properly with my configuration so I went back to fglrx once it became compatible with 13.2
I am experiencing some randomness in the behaviour after STR (suspend to ram).
I have tried three different methods to initiate Suspend:
- From a konsole CLI, execute ‘systemctl suspend’ as user
- From desktop, choose Launcher-Leave-Sleep
- I have a Hot Key combination “Ctrl+Alt+Z” mapped to KDE Daemon-Sleep as a GlobalKeyboard Shortcut under System Settings-ShortCuts and Gestures (my preferred method only because it is quick to implement)
I also have pm-utils 1.4.1 installed as I have migrated forward from a legacy configuration.
Sleeping using methods 2 and 3 enters Sleep OK, but waking fails to restore the display perhaps one time in 3 or 1 time in 5, i.e. a nuisance occasionally.
Method 1 I tried once - Sleep mode was entered very fast (seemed faster than 2 or 3) but on wake up one of the two displays was garbled badly, only a reboot would clear it.
Should all 3 of these initiate sleep methods deliver identical results?
Method 1 seemed much faster to blank the screen(go to sleep)
System cold boots fine, by the way, I just prefer sleep.
I am unclear if having pm-utils installed is OK, a bad idea, should be don’t care, etc.
The file it generates, /var/log/pm-suspend.log does not reveal any issues on shutdown.
Any thoughts?
For anyone who looks here with similar issue, THIS slightly older thread describes my issue fairly well, but does not seem to end with any resolution.
As a test, I removed pm-utils from my system.
I see some info about sleep and wake by executing ‘dmesg’, there is no longer a /var/log/pm-suspend.log generated on sleep, as expected.
I do wish dmesg had a more easily readable timeline.
I ran one Sleep-then-Resume cycle, worked OK.
So removing pm-utils is no worse than with it installed, I’ll see if some of the flakiness is reduced or resolved over time.
Actually this output might be useful/informative
dmesg |grep PM:
0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x0009efff]
0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000dffff]
0.000000] PM: Registered nosave memory: [mem 0x000e0000-0x000fffff]
0.000000] PM: Registered nosave memory: [mem 0xbf79a000-0xbf8fefff]
0.000000] PM: Registered nosave memory: [mem 0xbf8ff000-0xbfb01fff]
0.000000] PM: Registered nosave memory: [mem 0xbfd0e000-0xbfd5bfff]
0.000000] PM: Registered nosave memory: [mem 0xbfd5c000-0xbfd64fff]
0.000000] PM: Registered nosave memory: [mem 0xbfd65000-0xbfd67fff]
0.000000] PM: Registered nosave memory: [mem 0xbfd69000-0xbfea8fff]
0.000000] PM: Registered nosave memory: [mem 0xbfea9000-0xbfeb9fff]
0.000000] PM: Registered nosave memory: [mem 0xbfeba000-0xbfec7fff]
0.000000] PM: Registered nosave memory: [mem 0xbfec8000-0xbfec8fff]
0.000000] PM: Registered nosave memory: [mem 0xbfec9000-0xbfed8fff]
0.000000] PM: Registered nosave memory: [mem 0xbfed9000-0xbfed9fff]
0.000000] PM: Registered nosave memory: [mem 0xbfeda000-0xbfedafff]
0.000000] PM: Registered nosave memory: [mem 0xbfedb000-0xbfee0fff]
0.000000] PM: Registered nosave memory: [mem 0xbfee1000-0xbfef3fff]
0.000000] PM: Registered nosave memory: [mem 0xbff00000-0xdfffffff]
0.000000] PM: Registered nosave memory: [mem 0xe0000000-0xefffffff]
0.000000] PM: Registered nosave memory: [mem 0xf0000000-0xfebfffff]
0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff]
0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfec0ffff]
0.000000] PM: Registered nosave memory: [mem 0xfec10000-0xfec10fff]
0.000000] PM: Registered nosave memory: [mem 0xfec11000-0xfecfffff]
0.000000] PM: Registered nosave memory: [mem 0xfed00000-0xfed00fff]
0.000000] PM: Registered nosave memory: [mem 0xfed01000-0xfed3ffff]
0.000000] PM: Registered nosave memory: [mem 0xfed40000-0xfed44fff]
0.000000] PM: Registered nosave memory: [mem 0xfed45000-0xfed60fff]
0.000000] PM: Registered nosave memory: [mem 0xfed61000-0xfed70fff]
0.000000] PM: Registered nosave memory: [mem 0xfed71000-0xfed7ffff]
0.000000] PM: Registered nosave memory: [mem 0xfed80000-0xfed8ffff]
0.000000] PM: Registered nosave memory: [mem 0xfed90000-0xfeffffff]
0.000000] PM: Registered nosave memory: [mem 0xff000000-0xffffffff]
0.000000] PM: Registered nosave memory: [mem 0x100000000-0x100000fff]
0.292658] PM: Registering ACPI NVS region [mem 0xbf8ff000-0xbfb01fff] (2109440 bytes)
0.292699] PM: Registering ACPI NVS region [mem 0xbfd0e000-0xbfd5bfff] (319488 bytes)
0.292707] PM: Registering ACPI NVS region [mem 0xbfd65000-0xbfd67fff] (12288 bytes)
0.292709] PM: Registering ACPI NVS region [mem 0xbfea9000-0xbfeb9fff] (69632 bytes)
0.292711] PM: Registering ACPI NVS region [mem 0xbfec8000-0xbfec8fff] (4096 bytes)
0.292712] PM: Registering ACPI NVS region [mem 0xbfed9000-0xbfed9fff] (4096 bytes)
0.292713] PM: Registering ACPI NVS region [mem 0xbfedb000-0xbfee0fff] (24576 bytes)
2.159308] PM: Checking hibernation image partition /dev/disk/by-id/ata-SanDisk_SDSSDXP120G_141084400034-part1
2.958857] PM: Hibernation image not present or could not be loaded.
4.045239] PM: Marking nosave pages: [mem 0x0009e000-0x000fffff]
4.045245] PM: Marking nosave pages: [mem 0xbf79a000-0xbfb01fff]
4.045259] PM: Marking nosave pages: [mem 0xbfd0e000-0xbfd67fff]
4.045262] PM: Marking nosave pages: [mem 0xbfd69000-0xbfef3fff]
4.045268] PM: Marking nosave pages: [mem 0xbff00000-0x100000fff]
4.045888] PM: Basic memory bitmaps created
4.088503] PM: Basic memory bitmaps freed
4.091102] PM: Starting manual resume from disk
4.091106] PM: Hibernation image partition 8:1 present
4.091107] PM: Looking for hibernation image.
4.091299] PM: Image not found (code -22)
4.091300] PM: Hibernation image not present or could not be loaded.
[20309.766391] PM: Syncing filesystems ... done.
[20309.848647] PM: Preparing system for mem sleep
[20309.852634] PM: Entering mem sleep
[20310.876630] PM: suspend of devices complete after 1022.898 msecs
[20310.877423] PM: late suspend of devices complete after 0.789 msecs
[20310.889560] PM: noirq suspend of devices complete after 12.127 msecs
[20310.894187] PM: Saving platform NVS memory
[20310.901803] PM: Restoring platform NVS memory
[20310.956296] PM: noirq resume of devices complete after 11.440 msecs
[20310.956957] PM: early resume of devices complete after 0.613 msecs
[20320.699493] PM: resume of devices complete after 9736.702 msecs
[20320.709401] PM: Finishing wakeup.
[40726.321269] PM: Syncing filesystems ... done.
[40726.683980] PM: Preparing system for mem sleep
[40727.901636] PM: Entering mem sleep
[40728.938828] PM: suspend of devices complete after 1035.738 msecs
[40728.940724] PM: late suspend of devices complete after 1.889 msecs
[40728.953683] PM: noirq suspend of devices complete after 12.947 msecs
[40728.962476] PM: Saving platform NVS memory
[40728.973328] PM: Restoring platform NVS memory
[40729.027653] PM: noirq resume of devices complete after 11.274 msecs
[40729.028351] PM: early resume of devices complete after 0.648 msecs
[40738.661136] PM: resume of devices complete after 9627.418 msecs
[40738.671271] PM: Finishing wakeup.
I assume the info at [0.0000] are boot messages, subsequent activity related to suspend and resume actions.
|| This might be worth a shot. Following a resume, can you switch VT and back gain to gain a working graphical environment? (eg pressing Ctrl-Alt-F2, then Ctrl-Alt-F7). If that works, it can be automated (implemented as a script) using appropriate systemd services
|—|
http://www.freedesktop.org/software/systemd/man/systemd-suspend.service.html
|
Interesting discussion here on this topic
https://forum.kde.org/viewtopic.php?f=111&t=121590
There is a reference in that thread to the following openSUSE thread (post 132 onwards)
https://forums.opensuse.org/showthread.php/494706-openSUSE-13-1-KDE-inconsistant-resume-from-Suspend-to-RAM?p=2667244#post2667244
Maybe the workaround will help you too. I wonder if the compositor disable/enable lines could be incorporated into the sleep/resume services as well?
Thanks, Deano, I’ll give it a go in the AM
I reviewed this thread https://forum.kde.org/viewtopic.php?f=111&t=121590 , which IS an interesting read but does not really seem to reveal any single point of failure.
I did find out that when pm-utils are removed, it would seem that required tweaks to the process can be placed in the directory /usr/lib/systemd/system-sleep/, which in my case is currently empty.
I’ll try the kwin restart procedure next time I have the garble issue - so far, I am good (for no known reason).
For now, I am using only this method to enter suspend: KDE Desktop: Launcher-Leave-Sleep.
This is simply to reduce the number of variables in the test.
One interesting observation:
I have now had three successful Sleep-resume cycles since deleting package pm-utils.
All three were initiated with:KDE Desktop: Launcher-Leave-Sleep.
The first two instances, the system just entered sleep mode.
The third(last night), I got a pop-up saying that to execute sleep, it needed root permission.
I entered root password, sleep happened immediately.
I now find this :
loginctl
SESSION UID USER SEAT
49 1000 carl seat0
1 1000 carl seat0
c1 4 lp
Somehow, I seem to be logged in twice.
Not sure why this is, but perhaps the need for root permission resulted from system thinking other users were active (?).
On 2015-05-29 17:56, cmcgrath5035 wrote:
> I do wish dmesg had a more easily readable timeline.
dmesg has some options to adjust how it displays timestamps - see man dmesg.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Thanks, Carlos
Yes,
dmesg -T
....
[Sun May 31 05:33:44 2015] <6>[fglrx] Reserved FB block: Unshared offset:1fff3000, size:d000
[Sun May 31 05:33:45 2015] r8169 0000:03:00.0 eth0: link up
[Sun May 31 05:33:45 2015] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[Sun May 31 05:33:52 2015] NET: Registered protocol family 17
[Sun May 31 05:33:53 2015] fuse init (API version 7.23)
[Sun May 31 05:33:57 2015] Bluetooth: RFCOMM TTY layer initialized
[Sun May 31 05:33:57 2015] Bluetooth: RFCOMM socket layer initialized
[Sun May 31 05:33:57 2015] Bluetooth: RFCOMM ver 1.11
[Sun May 31 06:13:03 2015] plugin-containe[3439]: segfault at 0 ip 00007fe313933d6e sp 00007ffdf1421410 error 6 in libmozalloc.so[7fe313931000+5000]
[Sun May 31 06:13:19 2015] plugin-containe[3468]: segfault at 0 ip 00007f9f9265ad6e sp 00007ffd7cbc96e0 error 6 in libmozalloc.so[7f9f92658000+5000]
[Sun May 31 06:48:10 2015] capability: warning: `VirtualBox' uses 32-bit capabilities (legacy support in use)
[Sun May 31 06:49:04 2015] device eth0 entered promiscuous mode
[Sun May 31 07:03:11 2015] device eth0 left promiscuous mode
[Sun May 31 07:03:12 2015] vboxnetflt: 145 out of 9846 packets were not sent (directed to host)
Does help, for now at least, as I had to reboot.
The bigger issue, unavoidable as I understand, is that dmesg uses running time (time since start) which becomes seriously disconnected from real time when one suspends a system.
Other News: Last night I had my first failure since removing pm-utils, this time the suspend process failed, resulted in a frozen display of messages in dmesg format.
The error appeared to be deep into fglrx, my only solution was to power off manually, thus message is lost.
Still flaky, presumably in the fglrx driver.
Other News: Last night I had my first failure since removing pm-utils, this time the suspend process failed, resulted in a frozen display of messages in dmesg format.
The error appeared to be deep into fglrx, my only solution was to power off manually, thus message is lost.
Still flaky, presumably in the fglrx driver.
You should try manually disabling compositing (desktop effects) before suspending with Alt-Shift-F12 or the following (as user)
qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing
Then see how resuming behaves, and turn it back on with the same short-cut or command. If you can get reliable suspend/resume behaviour that way, it may be possible to automate…or maybe just leave desktop effects disabled.
Hmmm, strange results trying your suggestions , Carlos.
I have had Desktop effects set Enable at startup in System Settings-Desktop Effects.
Attempts to toggle off, using either method you suggest, seems to crash kwin (or ?).
Both displays go blank, but remain On with an ‘_’ at top left, as does the motherboard.
My only recovery seems to be power off then back on.
Attempts to initiate sleep are failing now as well.
I don’t “think” I have changed anything else.
Continuing to hack wit it.
The good news is that system reboots real fast with OS on an SSD 
Have you run a memory test??
On 2015-05-31 13:36, cmcgrath5035 wrote:
>
> Thanks, Carlos
> Yes,
> Code:
> --------------------
> dmesg -T
> …
> [Sun May 31 06:48:10 2015] capability: warning: `VirtualBox’ uses 32-bit capabilities (legacy support in use)
> --------------------
Is that a virtual machine?
> The bigger issue, unavoidable as I understand, is that dmesg uses
> running time (time since start) which becomes seriously disconnected
> from real time when one suspends a system.
No, you have a choice. Your code dump above shows real wall time.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On 2015-05-31 15:46, cmcgrath5035 wrote:
>
> Hmmm, strange results trying your suggestions , Carlos.
Mmm. No, those were from deano.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Gogalthorpe - good idea, but passed 5 cycles of test (memtest86) so for now I don’t think it is memory.
Carlos
My dmesg -T snippet was not from a VM, I pulled an example from period of time in which I had opened and closed a VM (WinXP_32).
Am I misinterpreting : ?
man dmesg
....
....
-T, --ctime
Print human-readable timestamps.
Be aware that the timestamp could be inaccurate! The time source used for the logs is not updated after system SUSPEND/RESUME.
....
So memory seems good, I’ll keep experimenting.
Not a all sure why attempting to toggle DeskTop Effects off causes kwin (I think) to blow up
I’ve always found suspend to memory flaky even in Windows.
Leave the memory test run over night at least.
On 2015-05-31 20:16, cmcgrath5035 wrote:
> Carlos
> My dmesg -T snippet was not from a VM, I pulled an example from period
> of time in which I had opened and closed a VM (WinXP_32).
>
> Am I misinterpreting : ?
No, it was me.
>
> Code:
> --------------------
> man dmesg
> …
> …
>
> -T, --ctime
> Print human-readable timestamps.
>
> Be aware that the timestamp could be inaccurate! The time source used for the logs is not updated after system SUSPEND/RESUME.
>
>
> …
>
> --------------------
You are absolutely right. I just looked at my dmesg output, and the dates say May 28, which doesn’t make sense. So I connected a usb stick, and sure enough:
[Thu May 28 15:44:05 2015] sdb:
[Thu May 28 15:44:05 2015] sd 7:0:0:0: [sdb] Attached SCSI removable disk
which on syslog (messages file) is different:
<0.6> 2015-06-01 00:30:08 minas-tirith kernel - - - [90086.828302] sdb:
<0.5> 2015-06-01 00:30:08 minas-tirith kernel - - - [90086.830150] sd 7:0:0:0: [sdb] Attached SCSI removable disk
I was not aware of this 
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Welcome to those of us disappointed with this.
Apparently the dmesg architects never suspend their computers 
On 2015-06-01 03:06, cmcgrath5035 wrote:
>
> Welcome to those of us disappointed with this.
>
> Apparently the dmesg architects never suspend their computers
It must be deeper than that. It is the kernel itself, that uses relative
times for the internal log. dmesg simply displays them.
I don’t remember if you tried looking at /var/log/messages? Failing
that, journalctl.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Did you try toggling the desktop effects with the keyboard short-cut as well? Or do both methods (command and short-cut) cause problems?
I’ve also read of some users changing to VT1 then suspending, and switching back to VT7 (desktop environment) upon resume, but they are generally using pm-utils (which I understand KDE will use if present)?