[ltp] Re: Trying to get Suspend to RAM working on an X31

Sun, 16 Nov 2014 00:49:13 -0800

Hi,

* fle <flaborderie@yahoo.fr> [141112 15:06]:
> I've been able to solve the power management issue. See the link.
> http://ubuntuforums.org/showthread.php?t=2249876&p=13165175#post13165175

Thanks for passing this along. I've pasted some of what you wrote in
that linked forum post here along with my comments and commentary on
what's worked for me.

> So as a summary, these are my settings :
> 
> 0- install xubuntu 14.04

Just for reference, I believe xubuntu 14.04 would have a 3.13.7 kernel,
and I'm running a 3.16.5 kernel.

> 1- etc/default/grub settings :
> 
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset video=radeonfb:force_sleep"
> then update-grub

These options work for me as well. The boot parameter I found earlier
( https://www.libreoffice.org/bugzilla/show_bug.cgi?id=38554#c2 )
that allowed resume from suspend to work was "radeon.modeset=0"
(nomodeset by itself did not work), so I simply used this:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.modeset=0"

That along with this suspend script did the job:

    #!/bin/sh
    sudo ifdown eth1
    sudo iwconfig eth1 txpower off
    sudo rmmod ehci_pci
    sudo rmmod ehci_hcd
    sudo rmmod uhci_hcd
    # Switch to vt6 to run pm-suspend (issues with backlight staying
    # on when done from X), stay in vt6 for a sec when waking to make
    # sure everything wakes up before switching back to X...
    FGCONSOLE=`fgconsole`
    chvt 6
    sleep 1
    /usr/sbin/pm-suspend --quirk-radeon-off
    sleep 1
    chvt $FGCONSOLE
    sudo modprobe uhci_hcd
    sudo modprobe ehci_hcd
    sudo modprobe ehci_pci
    sudo iwconfig eth1 txpower off

(pm-suspend doesn't work in X (I'm running X now), that's why this
switches to another VT to run pm-suspend. Not sure how important is
is to unload & reload those modules, or if it would help to unload
more...)

Now resume from suspend was working, but I noticed a less responsive
display, more hysteresis when re-sizing & dragging around windows in
cwm as well as a more sluggish and stuttering linewise scrolling in
Vim, etc. On a whim I tried `modprobe radeonfb`, and lo, the graphics
were more responsive -- no more sluggish stuttering hysteresis. But
the colors were all messed up... seemed to be a color depth issue.
Putting this in /etc/X11/xorg.conf fixed it:

     Section "Screen"
             Identifier "Screen0"
             DefaultDepth  24
     EndSection

> 2- use of radeonfb :
> as here http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep

Some relevant info on that page I somehow overlooked the last time I
took a look at it... The ACPI_sleep_power_drain_test_script looks like
it could be useful for troubleshooting. Also, this:

    You must use a recent (or patched) version of the radeonfb driver,
    even if you are only interested in using the X window system. The
    radeon frame buffer suspends the radeon chip correctly during ACPI
    sleep. Starting with linux 2.6.18, this patch is in the official
    (kernel.org) kernels.

> * edit /etc/initramfs-tools/modules and add the line "radeonfb"
> * sudo update-initramfs -u
> * edit /etc/modprobe.d/blacklist-framebuffer and comment out the line
>   "blacklist radeonfb"

I tried this approach, but found that it took longer to log into X and
longer to resume from suspend than when loading radeonfb *after* X is
running. So I added `sudo modprobe radeonfb &` to my ~/.xinitrc file.
A non-standard way to load kernel modules, but here's what I found:

Approach A - modprobe radeonfb in ~/.xinitrc
--------------------------------------------

9s to grub prompt
33s to login prompt
7s after login till visible cursor in X

Suspend to RAM:
5s to sleep
6-7s to wake

Suspend to disk:
10s to sleep
22s to wake

Approach B - via /etc/initramfs-tools/modules
---------------------------------------------

9s to grub prompt
35s to login prompt
15s after login till visible cursor in X

Suspend to RAM:
6s to sleep
15s to wake

Suspend to disk:
12s to sleep
32s to wake

By loading radeonfb the more "correct" way, the resume from suspend to
RAM time got bumped up from 7 to 15 seconds -- a bit longer than I'd
like, and also getting close to the 22 seconds for resuming from the
suspend-to-disk in approach A...which I'm thinking can be shaved down
even more by switching from a spinning magnetic HD to an SSD.

And suspend-to-disk is working pretty reliably running `pm-hibernate`
(within X, no need to switch to another VT) -- 55 hibernate/resume
cycles so far without fail.

Suspend to RAM on the other hand still occasionally fails to resume,
forcing a hard reboot (blank screen, no backlight, keyboard input not
recognized). This seems to happen about 1 time in 25, which really
isn't reliable enough for me. Haven't tried many suspend-to-ram/resume
cycles with the addition of the /etc/pm/config.d/99_ATI_RADEON
outlined below along with passing the "video=radeonfb:force_sleep"
boot parameter, maybe I'll try that next to see if it reduces
frequency of this resume failure.

At this point however I'm leaning towards going with suspend-to-disk
as a "sleep" solution. Will see if after swapping in an SSD that might
be reasonably fast enough. I was wondering if repeated suspend-to-disk
cycling might hurt an SSD, but this comment claims it's not a problem:

http://www.tomshardware.com/answers/id-2214313/hibernate-mode-ssd.html#response-13691628

> 3- then create the /etc/pm/config.d/99_ATI_RADEON file, as said previously with the following :
> 
> DROP_PARAMETERS=all
> ADD_PARAMETERs="--quirk-radeon-off --quirk-save-pci"

I had suspend/resume working ok without the "--quirk-save-pci" option,
but am adding it in for good measure along with "DROP_PARAMETERS=all",
will see how it works going forward.

> 4- install radeontool via the software center

Did you end up using radeontool for anything? I tried it in my suspend
script to no avail. What I found is that the machine would go to
sleep, backlight shut off, then immediately *after* the machine was
asleep the backlight would pop back on. The only thing that would
prevent this was passing the "--quirk-radeon-off" option. Also, fwiw
http://www.thinkwiki.org/wiki/Radeontool claims that radeontool is
deprecated, with the suggestion to use xrandr and sysfs instead.

* * * *

One workaround to the X31/X32 suspend/resume problems suggested to me
was to run an older kernel & version of X. Haven't tried running an
older kernel yet... but if choosing to do so, this indicates problems
started after kernel 2.6.31:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561926/comments/9

I'd prefer to stay with a more recent kernel to catch security
bug-fixes & such. For now I'm happy enough with suspend-to-disk
working reliably as-is. Hopefully the solution of using radeonfb and
the various other options listed above will continue to work in the
face any future changes to the radeon drivers, for example:

AMD Radeon Graphics Get Many Changes For Linux 3.17
http://www.phoronix.com/scan.php?page=news_item&px=MTc1NTg

[pull] radeon drm-next-3.17
http://lists.freedesktop.org/archives/dri-devel/2014-August/065525.html

Regards,

John

-- 
John Magolske
http://B79.net/contact