S3 sleep / suspend to ram on Ubuntu 18.04

[ventus_orientis]

Hey,
It seems to me that the Pinebook Pro does only enter into S1 suspend when closing the lid or pressing the power button. At least the output of journalctl | grep "PM: suspend" | tail doesn't indicate any form of deep suspend and my battery drain is around 3% / h which seems quite high.
Does anyone know how to change this behavior? I would prefer a deeper suspend, even for the price of a longer wake-up time.
Ideally I would like to set the suspend mode to s3 which is suspend to ram (meaning mostly anything exept for the ram self refresh is turned off).

Thanks in advance!

[pfeerick]

Um... unless I'm completely missing some recent change... ARM processors such as the RK3399 don't have ACPI sleep states such as S1 and S3!

3% / h does sound like something isn't being powered down. ARM processors are pretty good at going into a real low power sleep... i.e. my 11" Pinebook (1st gen, not the Pro) with the A64 cpu can be left in sleep mode for weeks, not the day and a half, that it seems your PBP would be in.

Out of curiosity (since I don't have a PBP yet, so this may not even work), does

Code:

echo mem > /sys/power/state

put it into sleep mode? Maybe it's not going to sleep properly?

[Arglebargle]

I was having problems with mine not sleeping properly overnight too. In my case it turned out that I was plugging/unplugging the machine after it'd gone to sleep which wakes it up.

It seems like it's not widely known that plugging/unplugging power will bring the machine out of sleep mode, and it's really easy to not notice this if the lid is already closed.

I'm not sure how long the machine stays awake before going back to sleep but the first night I had mine I put it to sleep then unplugged it and it was almost dead in the morning.

[ventus_orientis]

Oh, I didn't realize that ARM worked differently in this regard as well!
Could the high stand-by consumption been related to mounting a sd-card as /home?
Maybe it prevents a complete shut down?
Where could I find a log to check something like that?

also it is not related to having the pbp plugged in or not since it happend while putting it to sleep on battery and (obviously, I guess) I didn't plug it in while it was sleeping.

echoing mem to power state seems not to be allowed to sudo or normal users

[ventus_orientis]

Ok, here I am again:

echoing mem to power state does work while logged in as root and only then.
It suspends the pinebook pro but doesn't require a password when waking it up
it seems to me that it doesn't change battery consumption when compared to closing the lid.

Does anybody know how I can find out what keeps my pbp from suspending correctly?

[wasgurd]

I've got the same problem:

After I closed the lid the laptop gets hot with dramatically increasing of power consumption.

Code:

sudo journalctl | grep "PM: suspend"
Jan 17 00:06:00 pinebookpro kernel: PM: suspend entry (s2idle)
Jan 17 00:06:16 pinebookpro kernel: PM: suspend devices took 1.050 seconds
Jan 17 00:06:16 pinebookpro kernel: PM: suspend exit

Code:

[Fri Jan 17 00:05:59 2020] PM: suspend entry (s2idle)
[Fri Jan 17 00:05:59 2020] Filesystems sync: 0.007 seconds
[Fri Jan 17 00:05:59 2020] dwmmc_rockchip fe310000.dwmmc: pre_suspend failed for non-removable host: -38
[Fri Jan 17 00:05:59 2020] Freezing user space processes ... (elapsed 0.025 seconds) done.
[Fri Jan 17 00:05:59 2020] OOM killer disabled.
[Fri Jan 17 00:05:59 2020] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[Fri Jan 17 00:05:59 2020] printk: Suspending console(s) (use no_console_suspend to debug)
[Fri Jan 17 00:06:00 2020] PM: suspend devices took 1.050 seconds
[Fri Jan 17 00:06:15 2020] usb usb5: root hub lost power or was reset
[Fri Jan 17 00:06:15 2020] usb usb6: root hub lost power or was reset
[Fri Jan 17 00:06:15 2020] usb usb7: root hub lost power or was reset
[Fri Jan 17 00:06:15 2020] usb usb8: root hub lost power or was reset
[Fri Jan 17 00:06:15 2020] PM: resume devices took 0.420 seconds
[Fri Jan 17 00:06:15 2020] OOM killer enabled.
[Fri Jan 17 00:06:15 2020] Restarting tasks ... done.
[Fri Jan 17 00:06:15 2020] PM: suspend exit
[Fri Jan 17 00:06:15 2020] vcc_sdio: unsupportable voltage range: 3300000-3000000uV
[Fri Jan 17 00:06:15 2020] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[Fri Jan 17 00:06:15 2020] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[Fri Jan 17 00:06:16 2020] dwmmc_rockchip fe320000.dwmmc: Successfully tuned phase to 94
[Fri Jan 17 00:06:26 2020] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Debian Testing form the Unofficial Installer

[tophneal]

Which kernel does bullseye run, using that installer?

[z4v4l]

ACPI is not x86 only, ARM can perfectly have it, and linux could implement it (since it's the OS responsibility), but, it looks like it didn't. I mean even without ACPI tables that obviously are not present yet in rockchip's BSPs, it would be doable to implement ACPI Suspend To RAM and Hibernate sleep states - with the help of uboot, whose devs again probably deemed this functionality "gay".
I suspect, that the state PBP is put into, when the lid is closed is S none, meaning it's not a sleep state at all, since by the definition in all the S states, processor doesn't run. that means it should be waken up. without the firmware, understaning it's STR (meaning no SDRAM init needed and the different path of the initialization, handoff to the OS etc are needed)  the normal sleep states aren't possible then. only some lame hacks, varying from machine to machine instead. supporting this unmanageable mess of millions ways of doing the same thing is hard, so here the situation. when a suppossed to be sleep is frying your laptop. this is the price of neglecting and dismissive attitude towards ACPI from "some" circles. it's basically about "freedom". of ACPI. and as a result of the sleep states and battery charge.

[wasgurd]

Which kernel does bullseye run, using that installer?

Code:

uname -a
Linux pinebookpro 5.4.2-2-pinebookpro-arm64 #1 SMP PREEMPT Sat Jan 11 03:28:31 UTC 2020 aarch64 GNU/Linux

[danielt]

Which kernel does bullseye run, using that installer?

Code:

uname -a
Linux pinebookpro 5.4.2-2-pinebookpro-arm64 #1 SMP PREEMPT Sat Jan 11 03:28:31 UTC 2020 aarch64 GNU/Linux

Anything running Debian Bullseye is, assuming you used my installer and didn't change it afterwards, configured to do something called suspend-to-idle.

It means that when the laptop is asked to suspend to memory the kernel will prevent any tasks from being scheduled and close down most of the device drivers. Then it just waits... in other words is relies on normal kernel power management (cpufreq, cpuidle, etc) to minimise standby power. In principle by eliminating wakeups then we ensure that cpuidle can descend to it's deepest sleep state.

There are some power savings in this state (for example all the radios will get turned off) but they are pretty modest. I compared an s2idle system against a system doing nothing with the backlight turned off... s2idle ended up saving about a watt. So, not completely useless, but if I am going away for more than an hour I generally do a real power off instead.

It is configured this way because I wasn't able to get the system to turn back on after going into a deeper suspend state. There are some power savings but more importantly the laptop shouldn't hang when you close the lid: most desktop environments are configured to automatically suspend on lid-close and adopting s2idle means we don't have to hack each one separately to avoid the suspend.