Issues resuming from hibernation

[solitone]

I've got a debian stretch installation on a MacBookPro 12,1 (Retina, Early
2015). When I resume the system from hibernation, the Wi-Fi adapter doesn't
work any longer. I need to reboot the system to have it work again.

Besides, performance in general is pretty bad after resume. The system is not
responsive--e.g. windows in the desktop environment take tens of seconds to
open.

I've got a 7.5 GB swap partition (7812496 KiB), and 7.7 GiB of memory (8079104
KiB)--actually I chose 8 GB for swap during disk partitioning, but I didn't
get what I wanted, perhaps because of the giga vs. giga-binary thing.

After a first installation attempt, where I had just 3 or something GB of swap,
resume after hibernation didn't work at all. I got messages like the
following:

PM: Image loading progress: 0%
PM: Image loading progress: 10%
PM: Image loading progress: 20%
PM: Image loading progress: 30%
PM: Image loading progress: 40%

and then a black screen.

So I repartitioned the disk, increasing the swap partition, and reinstalled.
Now the system does start from hibernation, but there are the issues I
mentioned.

I hope it's not related to a swap partition slightly falling short of RAM.
Reinstallation is not an option now!

Please let me know what information I should provide, so that you can tell me
what I need to analyze.

Thanks!

[Richard Waterbeek]

Hi solitone,

You might want to consider, to not longer put the computer to
hibernation, but to use suspend. This way, you will not have to store
the memory state to harddisk, instead the RAM will stay on battery
power.

This state [I have a PC], is ACPI and the command to put the computer
sleeping is 'systemctl suspend'.

This way, you can make sure, if the loss of network connectivity has to
do with suspending RAM to harddisk, or not.

My laptop can stay suspended this way for several days. I would not be
surprised the problems you have, will go away this way. [I write this
because I am not surprised that most users can put their computer to
hibernate, and some don't] Suspending to RAM is safer bet, for a
computer to being able to restore everything.

Since systemctl is from systemd, I suspect that the command I just
wrote, will work for you.

For the Wi-fi adapter, I recommend, if you didn't have so already, to
use Gnome networkmanager [installer is named 'network-manager'] See;
https://boundarydevices.com/wp-content/uploads/2015/03/Screenshot-03032015-122125-PM2.png

If you really need to hibernate instead of suspending, I can't be of
much help. I have my reasons to prefer suspending over hibernation.
However, I would look in to 'pm-utils' which has;

/usr/sbin/pm-hibernate
/usr/sbin/pm-powersave
/usr/sbin/pm-suspend
/usr/sbin/pm-suspend-hybrid

If you already have 'pm-utils', which I'm not sure of, but for network
connections and suspending/ hibernating, different tools exist, so I
told this, to complete my answer to you issue.

Good luck.

--
Richard Waterbeek <richa...@versatel.nl>


solitone schreef op vr 23-12-2016 om 21:33 [+0100]:

[solitone]

On Friday, December 23, 2016 11:55:19 PM CET Richard Waterbeek wrote:
> You might want to consider, to not longer put the computer to
> hibernation, but to use suspend. This way, you will not have to store
> the memory state to harddisk, instead the RAM will stay on battery
> power.

> [...]

> This way, you can make sure, if the loss of network connectivity has to
> do with suspending RAM to harddisk, or not.

Hi Richard, and thanks for your feedback. Yes, I confirm the problem has indeed
to do with hibernation (suspending to disk). Since hibernation won't work
well, at the moment I regularly suspend to RAM, and everything works fine--also
Wi-Fi does.

> Suspending to RAM is safer bet, for a computer to being able to restore
everything.

> [...]

> I have my reasons to prefer suspending over hibernation.

I currently make do with suspend, however being my PC a laptop, I'd rather
also have the option to hibernate from time to time. This is why I'm looking
for a way to address the issues I have.

Thanks & Regards,
Davide

[solitone]

On Saturday, December 24, 2016 6:28:22 AM CET solitone wrote:
> I confirm the problem has indeed to do with hibernation (suspending to disk).

Specifically, here's the output of nmcli after either a cold startup or
resuming from RAM:
#####
solitone@alan:~$ nmcli
wlp3s0: connected to colossus
"Broadcom Limited BCM43602 802.11ac Wireless LAN SoC"
wifi (brcmfmac), 98:01:A7:9D:0F:BD, hw
ip4 default
inet4 192.168.0.30/24
inet6 fe80::9a01:a7ff:fe9d:fbd/64

lo: unmanaged
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
[...]
#####

Immediately after resuming from hibernation, here's what I got instead:
#####
solitone@alan:~$ nmcli

(process:2536): nmcli-CRITICAL **: Error: Could not create NMClient object:
Timeout was reached.
#####

After a couple of minutes I repeated the command, and got:
#####
solitone@alan:~$ nmcli
wlp3s0: disconnected
"Broadcom Limited BCM43602 802.11ac Wireless LAN SoC"
wifi (brcmfmac), 98:01:A7:9D:0F:BD, hw, mtu 1500

lo: unmanaged
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
[...]
#####

I tried to manually reconnect the device, but it didn't work:
#####
solitone@alan:~$ nmcli device connect wlp3s0
Error: Failed to add/activate new connection: A 'wireless' setting is required
if no AP path was given.
#####

[solitone]

And here are my NetworkManager's logs, from when I sent the request to
hibernate to disk (13:51:02), to the resume request (13:51:31). At 13:52:24 I
got a timeout error that I think prevents the network device from reactivating
correctly.

Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.2896] manager:
sleep requested (sleeping: no enabled: yes)
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.2897] manager:
sleeping...
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.2897] manager:
NetworkManager state is now ASLEEP
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.2900] device
(wlp3s0): state change: activated -> deactivating (reason 'sleeping') [100 110
37]
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.3016] device
(wlp3s0): state change: deactivating -> disconnected (reason 'sleeping') [110
30 37]
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.3355] dhcp4
(wlp3s0): canceled DHCP transaction, DHCP client pid 1152
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.3355] dhcp4
(wlp3s0): state changed bound -> done
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.8791] device
(wlp3s0): set-hw-addr: set MAC address to 8A:F5:D7:13:F3:8E (scanning)
Dec 24 13:51:02 alan NetworkManager[674]: <warn> [1482583862.8818] sup-
iface[0x561ae4e4a6d0,wlp3s0]: connection disconnected (reason -3)
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.8819] device
(wlp3s0): supplicant interface state: completed -> disconnected
Dec 24 13:51:02 alan NetworkManager[674]: <info> [1482583862.8824] device
(wlp3s0): state change: disconnected -> unmanaged (reason 'sleeping') [30 10
37]
Dec 24 13:51:03 alan NetworkManager[674]: <info> [1482583863.4248] device
(wlp3s0): set-hw-addr: reset MAC address to 98:01:A7:9D:0F:BD (unmanage)
Dec 24 13:51:31 alan NetworkManager[674]: <info> [1482583891.2109] manager:
wake requested (sleeping: yes enabled: yes)
Dec 24 13:51:31 alan NetworkManager[674]: <info> [1482583891.2110] manager:
waking up...
Dec 24 13:51:31 alan NetworkManager[674]: <info> [1482583891.2110] device
(wlp3s0): state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Dec 24 13:51:53 alan NetworkManager[674]: <warn> [1482583913.5823] device
(wlp3s0): set-hw-addr: new MAC address 8A:F5:D7:13:F3:8E not successfully set
(scanning)
Dec 24 13:51:59 alan NetworkManager[674]: <info> [1482583919.5946] manager:
NetworkManager state is now DISCONNECTED
Dec 24 13:52:24 alan NetworkManager[674]: <error> [1482583944.5976] sup-
iface[0x561ae4e4a4c0,wlp3s0]: error adding interface: Timeout was reached
Dec 24 13:52:24 alan NetworkManager[674]: <info> [1482583944.5978] device
(wlp3s0): supplicant interface state: starting -> down
Dec 24 13:52:35 alan NetworkManager[674]: <warn> [1482583955.1184] device
(wlp3s0): re-acquiring supplicant interface (#1).
Dec 24 13:52:35 alan NetworkManager[674]: <info> [1482583955.9549] sup-
iface[0x561ae4e4c2a0,wlp3s0]: supports 5 scan SSIDs
Dec 24 13:52:35 alan NetworkManager[674]: <info> [1482583955.9572] device
(wlp3s0): supplicant interface state: starting -> ready
Dec 24 13:52:35 alan NetworkManager[674]: <info> [1482583955.9572] device
(wlp3s0): state change: unavailable -> disconnected (reason 'supplicant-
available') [20 30 42]

[solitone]

One think I've noticed just today is that now neither hibernation to disk nor
suspension to RAM work as expected. The laptop goes to sleep, but immediately
after it automatically resumes without any input from me.

I'm sure some days ago this did not happen. It might be a side effect from
some recent package upgrade.

[Roberto Efraín Uribe Capulín]

Have you tried to add a swapfile to fstab? Just to check if it has something to do with not enough swap.

[solitone]

On Saturday, December 24, 2016 5:10:43 PM CET you wrote:
> Have you tried to add a swapfile to fstab? Just to check if it has
> something to do with not enough swap.

Hi Roberto, no, I haven't done it yet, although I'm pretty sure it has not to
do with swap size. I'm finding many errors on resume all pointing to something
wrong in the management of the network device.

Cheers & Marry Christmas :-)

[solitone]

On Saturday, December 24, 2016 2:05:25 PM CET solitone wrote:
> At 13:52:24 I got a timeout error that I think prevents the network device
from reactivating correctly.

Here are somo more details from syslog:

Dec 24 13:51:59 alan kernel: [ 620.183140] brcmfmac: brcmf_msgbuf_query_dcmd:
Timeout on response for query command
Dec 24 13:51:59 alan kernel: [ 620.183150] brcmfmac:
brcmf_cfg80211_set_power_mgmt: error (-5)
Dec 24 13:52:01 alan kernel: [ 622.199690] brcmfmac: brcmf_msgbuf_query_dcmd:
Timeout on response for query command
Dec 24 13:52:01 alan kernel: [ 622.199711] brcmfmac:
_brcmf_set_multicast_list: Setting mcast_list failed, -5
[...]
Dec 24 13:52:07 alan kernel: [ 628.248975] brcmfmac:
brcmf_cfg80211_get_channel: chanspec failed (-5)
Dec 24 13:52:09 alan kernel: [ 630.265516] brcmfmac: brcmf_msgbuf_query_dcmd:
Timeout on response for query command
Dec 24 13:52:09 alan kernel: [ 630.265522] brcmfmac:
brcmf_cfg80211_get_tx_power: error (-5)
[...]

Dec 24 13:52:24 alan NetworkManager[674]: <error> [1482583944.5976] sup-
iface[0x561ae4e4a4c0,wlp3s0]: error adding interface: Timeout was reached

[...]

There are those two kernel errors on brcmf_cfg80211_set_power_mgmt and
brcmf_cfg80211_get_tx_power that could be the root cause of the network issue.

[solitone]

On Saturday, December 24, 2016 2:08:57 PM CET solitone wrote:
> One think I've noticed just today is that now neither hibernation to disk
> nor suspension to RAM work as expected. The laptop goes to sleep, but
> immediately after it automatically resumes without any input from me.

This depends on the lid being open. If I close the lid, the laptop goes to
suspend (thanks to KDE's settings) and stays there. In contrast, when I
suspend from KDE's menu, it suspends but it wakes up immediately after.

I had a look at /proc/acpi/wakeup:

solitone@alan:~$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PEG0 S3 *disabled
EC S4 *disabled platform:PNP0C09:00
HDEF S3 *disabled pci:0000:00:1b.0
RP01 S3 *disabled pci:0000:00:1c.0
RP02 S3 *disabled pci:0000:00:1c.1
RP03 S3 *disabled pci:0000:00:1c.2
ARPT S4 *enabled pci:0000:03:00.0
RP05 S3 *disabled pci:0000:00:1c.4
RP06 S3 *disabled pci:0000:00:1c.5
SPIT S3 *disabled
XHC1 S3 *enabled pci:0000:00:14.0
ADP1 S4 *disabled platform:ACPI0003:00
LID0 S4 *enabled platform:PNP0C0D:00

So I decided to disable waking up through the lid:

solitone@alan:~$ sudo sh -c "echo LID0 > /proc/acpi/wakeup"
solitone@alan:~$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PEG0 S3 *disabled
EC S4 *disabled platform:PNP0C09:00
HDEF S3 *disabled pci:0000:00:1b.0
RP01 S3 *disabled pci:0000:00:1c.0
RP02 S3 *disabled pci:0000:00:1c.1
RP03 S3 *disabled pci:0000:00:1c.2
ARPT S4 *enabled pci:0000:03:00.0
RP05 S3 *disabled pci:0000:00:1c.4
RP06 S3 *disabled pci:0000:00:1c.5
SPIT S3 *disabled
XHC1 S3 *enabled pci:0000:00:14.0
ADP1 S4 *disabled platform:ACPI0003:00
LID0 S4 *disabled platform:PNP0C0D:00

Now when I suspend or hibernate with the menu entry it doesn't wake up unless
I press a key or touch the trackpad (when suspended) or press the power button
(when hibernated), as expected. Nice!

> I'm sure some days ago this did not happen. It might be a side effect from
> some recent package upgrade.

Mmm.. most likely I didn't remember it right. Perhaps I never tested it very
carefully, and simply didn't notice the issue.

[solitone]

So, I found out that removing the wifi driver after wake up from hibernation
(rmmod brcmfmac), and then reloading it again (modprobe brcmfmac) solves the
problem. The network starts to work again.

[solitone]

And here's the script I wrote to automate it:

#!/bin/sh
#
# /usr/lib/systemd/system-sleep/network_hack_hibernation
#
# Restores network functionality after wakeup from hibernation
#
# Tested on MacBookPro12,1
# BCM43602 WiFi network controller

if [ "$2" = "hibernate" ]; then
case "$1" in
pre)
if lsmod | grep -q brcmfmac; then
rmmod brcmfmac
fi
;;
post)
modprobe brcmfmac
;;
esac
fi

[solitone]

On Sunday, December 25, 2016 8:17:48 PM CET solitone wrote:
> This depends on the lid being open. If I close the lid, the laptop goes to
> suspend (thanks to KDE's settings) and stays there. In contrast, when I
> suspend from KDE's menu, it suspends but it wakes up immediately after.

BTW, this is not as it is supposed to work, is it? When the lid is open, and
the system suspends/hibernates, the lid sends a wakeup signal as soon as the
system has gone to sleep mode. This seems an odd behaviour. Perhaps it is the
laptop firmware that misbehaves.

In any case, as a workaround I've put the following script in /lib/systemd/
system-sleep/

#!/bin/sh
#
# /lib/systemd/system-sleep/lid_wakeup_disable
#
# Avoids that system wakes up immediately after suspend or hibernate
# with lid open (e.g. suspend/hibernate through KDE menu entry)

#
# Tested on MacBookPro12,1

case $1 in
pre)
if cat /proc/acpi/wakeup | grep -qE '^LID0.*enabled'; then
echo LID0 > /proc/acpi/wakeup
fi
;;
esac

[solitone]

As I wrote in a previous message, I solved the WiFi issue. However, I've
recently noticed another problem affecting the display.

If I turn the lid when the monitor is on, everything works fine--the laptop
hibernates, and when it resumes I get the monitor on.

If the monitor is already off (it switches off after several minutes of
inactivity) and then I close the lid, when the laptop resumes it starts
normally, the monitor turns on temporarily (I see boot messages), but in the
end it goes off again and there is no way to switch it on. I have to turn the
computer off and reboot it.

What can cause the problem? Is there a command to switch on the monitor just
before the system starts to hibernate? I'm thinking of putting that command in
a script in /usr/lib/systemd/system-sleep/

Cheers,
Davide

[solitone]

The monitor being off is for sure what causes the problem.

If I closed the lid at this precise moment, the system would hibernate and
then resume perfectly ok.

However, if I first ran the following command in a terminal to switch off the
screen:

$ sleep 1 && xset dpms force off

and then closed the lid, the system would hibernate, but then would resume and
switch off the screen. As I mentioned in my previous post, there is no way to
switch on the screen. The only thing I can do is reboot the system.

I've done plenty of tests, and this behaviour is always reproducible.

[Richard Waterbeek]

Hi Davide,

I was wondering if you got things working now. I've been reading along
and you made a good move by probing the wireless driver to the kernel
again when your machine comes back from sleep.

I've learned it is better to have nmcli with or without nmtui manage the
wireless connection, I have on top of that Gnome Network Manager, but
WICd also is a proper tool.

Do you have other strange things going on when the system comes back
from hibernation or is it only the wireless connection that is being
thrown out I wonder.

--
Richard Waterbeek <richa...@versatel.nl>
The Netherlands

solitone schreef op zo 25-12-2016 om 07:53 [+0100]:

[solitone]

On Tuesday, January 10, 2017 3:12:11 AM CET Richard Waterbeek wrote:
> Do you have other strange things going on when the system comes back
> from hibernation or is it only the wireless connection that is being
> thrown out I wonder.

Hi Richard,

now wireless network works perfectly well after resuming from hibernate.
There's another thing though, that I wrote about in another branch of this
thread.

If the screen is off and then the system hibernates, when it resumes the
screen is switched off again, and there's no way to turn it on. When the
system starts resuming the screen is on, I can see boot messages, but at the
end of the resume process the screen is switched off.

The system is perfectly up and running, and I can ssh into it. From ssh I've
checked that, after resume, I have the following values in the three backlight
files brightness, actual_brightness, and bl_power:

$ cat /sys/class/backlight/intel_backlight/brightness
1388
$ cat /sys/class/backlight/intel_backlight/actual_brightness

0
$ cat /sys/class/backlight/intel_backlight/bl_power
4

bl_power = 4 means the screen is off.

Trying the following command from ssh has no effect--it doesn't change the
value in bl_power, and the screen doesn't turn on:

$ xset -display :0 dpms force on

I get the issue everytime I hibernate with bl_power set to 4 (screen off).

I've sent a bug report, but I don't know whether it's the right place and it
will ever be considered:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850221

Thanks & Regards,
Davide

[Richard Waterbeek]

Hey solitone,

I happen to have '/sys/class/backlight/intel_backlight/' so I played
with that. I have been echoing to it.

I noticed that the values there don't seem to have a direct relation
with the actual brightness. By switching Fn + F7 and F8, different
values are put in those files.

What I mean with that is, I tap the function key three times down and
three times up, the backlight comes back to it's original luminance.
When I echo to that file the value shown at three times down, the
backlight changes, but after this, I can't get it to it's original
setting, with echoing the value that was shown. After this, by using the
function key, down and up, till I can tell it is the same luminance,
then the value shown isn't any longer the same.

Are you sure you need to switch the backlight off I ask. I reckon, the
backlight comes with it's own electronics, but by echoing a real low
value, it isn't actually turned off [according to the kernel I suppose],
and then you can echo to it, to see if you can get your preferred value,
and if this is stable [the backlight luminance stays at what you have
echo'd to it]

I'm not sure if this will be helpful, but it is helpful to see if
echoing '0' to it, gives the same problem.

Also, when you are confident how the kernel/ backlight responds to a low
value and zero value, then, if the system hibernates, you can remove the
battery, wait a moment, put it back in [to make sure your laptop is
really without current], see if that comes back [I suppose it will,
hence it hibernates], then you can be sure you won't have to turn off
the backlight.

Let me know if I missed something. Also, you might want to give xrandr/
xbacklight a try.

--
Richard Waterbeek <richa...@versatel.nl>
The Netherlands

solitone schreef op di 10-01-2017 om 07:01 [+0100]:

[solitone]

On Thursday, January 12, 2017 1:43:38 AM CET Richard Waterbeek wrote:
> I noticed that the values there don't seem to have a direct relation
> with the actual brightness.

No, in my case they do relate with brightness.

> What I mean with that is, I tap the function key three times down and
> three times up, the backlight comes back to it's original luminance.
> When I echo to that file the value shown at three times down, the
> backlight changes, but after this, I can't get it to it's original
> setting, with echoing the value that was shown. After this, by using the
> function key, down and up, till I can tell it is the same luminance,
> then the value shown isn't any longer the same.

This works different in my system. If I reduce the brightness by half with F-
keys, actual_brighness changes from 1388 to 763. If I go back to maximum
brightness, and then echo 763 to brightness, the screen brightness is indeed
half, as expected.

> Are you sure you need to switch the backlight off I ask.

This is what happens with the standard KDE's power management funtionality.
After some time the system is inactive, the screen is turned off.

[solitone]

On Thursday, January 12, 2017 1:45:48 AM CET you wrote:
> p.s. I forgot to ask, you wrote; 'There's another thing though, that I
> wrote about in another branch of this thread.'
>
> What branch and what thread is that. Did you mean another mailinglist
> maybe.

No, in this same mailing list, and in this very thread. I just mean a "sub-
thread branch", but the thread is the same actually.