Page 1 of 5 123 ... LastLast
Results 1 to 10 of 44

Thread: Suspend to Ram seems falky

  1. #1
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Suspend to Ram seems falky

    I have been watching this forum item https://forums.opensuse.org/showthre...pend-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:
    1. From a konsole CLI, execute 'systemctl suspend' as user
    2. From desktop, choose Launcher-Leave-Sleep
    3. 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?
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  2. #2
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: Suspend to Ram seems flaky

    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.
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  3. #3
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: Suspend to Ram seems falky

    Actually this output might be useful/informative
    Code:
    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.
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  4. #4
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,381
    Blog Entries
    1

    Default Re: Suspend to Ram seems falky

    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/...d.service.html



  5. #5
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,381
    Blog Entries
    1

    Default Re: Suspend to Ram seems falky

    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/showthre...44#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?

  6. #6
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: Suspend to Ram seems falky

    Thanks, Deano, I'll give it a go in the AM
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  7. #7
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: Suspend to Ram seems falky

    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 :
    Code:
     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 (?).
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  8. #8
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Suspend to Ram seems falky

    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))

  9. #9
    Join Date
    Jun 2008
    Location
    Florida, USA
    Posts
    970

    Default Re: Suspend to Ram seems falky

    Thanks, Carlos
    Yes,
    Code:
     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.
    Desk: i7-4790K Leap 15.1(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0
    Lap: HPDV7T i7 Leap 15.0(x86_64)4.12.14-lp151.28.7-default KF5 59.0 Plasma 5.14.4 Qt 5.13.0

  10. #10
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,381
    Blog Entries
    1

    Default Re: Suspend to Ram seems falky

    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)
    Code:
    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.

Page 1 of 5 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •