linux-next on x60: network manager often complains "network is disabled" after resume

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek wrote:

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
									Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Woody

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
								Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims
that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
									
Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Where does the complaint occur?  In the GUI, or with nmcli, or
somewhere else?  Also, what's the output of "nmcli dev" after resume?

Dan

On Mon 2018-03-19 10:40:08, Dan Williams wrote:

On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims
that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
									
Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Where does the complaint occur?  In the GUI, or with nmcli, or
somewhere else?  Also, what's the output of "nmcli dev" after resume?

In the GUI. I click in place where I'd select access point, and menu
does not show up, telling me that "network is disabled".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:

On Mon 2018-03-19 10:40:08, Dan Williams wrote:

quoted

On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often
claims
that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
								
	
Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Where does the complaint occur?  In the GUI, or with nmcli, or
somewhere else?  Also, what's the output of "nmcli dev" after
resume?

In the GUI. I click in place where I'd select access point, and menu
does not show up, telling me that "network is disabled".

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Dan

On Mon 2018-03-19 12:45:49, Dan Williams wrote:

On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 10:40:08, Dan Williams wrote:

quoted

On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often
claims
that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
								
	
Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Where does the complaint occur?  In the GUI, or with nmcli, or
somewhere else?  Also, what's the output of "nmcli dev" after
resume?

In the GUI. I click in place where I'd select access point, and menu
does not show up, telling me that "network is disabled".

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --
pavel@amd:~$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN
enabled  enabled  enabled  enabled
pavel@amd:~$ uname -a
Linux amd 4.16.0-rc5-next-20180314+ #31 SMP Thu Mar 15 14:27:19 CET
2018 i686 GNU/Linux

Let me suspend/resume. I was lucky and got it into working state:

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
wlan0   wifi      connected    openwireless.org
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
pavel@amd:~$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN
enabled  enabled  enabled  enabled
pavel@amd:~$

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Tue, 2018-03-20 at 09:03 +0100, Pavel Machek wrote:

On Mon 2018-03-19 12:45:49, Dan Williams wrote:

quoted

On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 10:40:08, Dan Williams wrote:

quoted

On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often
claims
that
"network is disabled". Sometimes suspend/resume clears
that.

Any ideas? Does it work for you?
								
	
Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not
fixed,
problem will appear in 4.17-rc1.

Where does the complaint occur?  In the GUI, or with nmcli, or
somewhere else?  Also, what's the output of "nmcli dev" after
resume?

In the GUI. I click in place where I'd select access point, and
menu
does not show up, telling me that "network is disabled".

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to debug
further.  Before you suspend, run "nmcli gen log level trace" to turn
on full debug logging, then reproduce the issue, and send a pointer to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.

Dan

pavel@amd:~$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN
enabled  enabled  enabled  enabled
pavel@amd:~$ uname -a
Linux amd 4.16.0-rc5-next-20180314+ #31 SMP Thu Mar 15 14:27:19 CET
2018 i686 GNU/Linux

Let me suspend/resume. I was lucky and got it into working state:

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
wlan0   wifi      connected    openwireless.org
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
pavel@amd:~$ nmcli radio
WIFI-HW  WIFI     WWAN-HW  WWAN
enabled  enabled  enabled  enabled
paveamd:~$

Best regards,
									
Pavel

Pavel Machek wrote:

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
									Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Works here OK. Tried ~10 suspends, all restarted OK.
kernel next-20180320
nmcli shows that Wifi always connects OK

Woody

Woody Suwalski wrote:

Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
                                    Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Works here OK. Tried ~10 suspends, all restarted OK.
kernel next-20180320
nmcli shows that Wifi always connects OK

Woody

Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
I think that Dan's suspicion is correct - it is a snafu in the PM: trying to hibernate results in a message:
Failed to hibernate system via logind: There's already a shutdown or sleep operation in progress.

And ps shows "Ds /lib/systemd/systemd-sleep suspend"...

Woody

quoted

quoted

Ok, what does 'nmcli dev' and 'nmcli radio' show?

quoted

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to debug
further.  Before you suspend, run "nmcli gen log level trace" to turn
on full debug logging, then reproduce the issue, and send a pointer to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.

Hmm :-)

root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'
root@amd:/data/pavel# nmcli gen log level help
Error: Unknown log level 'help'
root@amd:/data/pavel# nmcli gen log level
Error: value for 'level' argument is required.
root@amd:/data/pavel# nmcli gen log level debug
root@amd:/data/pavel# cat /var/log/sys/log

Where do I get the logs? I don't see much in the syslog...

And.. It seems that it is "every other suspend". One resume results in
broken network, one in working one, one in broken one...

Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:

quoted

quoted

quoted

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a
problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to debug
further.  Before you suspend, run "nmcli gen log level trace" to
turn
on full debug logging, then reproduce the issue, and send a pointer
to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.

Hmm :-)

root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'

What NM version?  'trace' is pretty old (since 1.0 from December 2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it.  Anyway, debug would do.

root@amd:/data/pavel# nmcli gen log level help
Error: Unknown log level 'help'

nmcli gen help

root@amd:/data/pavel# nmcli gen log level
Error: value for 'level' argument is required.
root@amd:/data/pavel# nmcli gen log level debug

This should be OK.

root@amd:/data/pavel# cat /var/log/sys/log

It routes it to whatever the syslog 'daemon' facility logs to (however
that's configured on your system).  Usually /var/log/messages or
/var/log/daemon.log or sometimes your distro configures it to
/var/log/NetworkManager.log.

Or if you're using a systemd-based distro, it would probably be in the
systemd journal so "journalctl -b -u NetworkManager"

Where do I get the logs? I don't see much in the syslog...

And.. It seems that it is "every other suspend". One resume results
in
broken network, one in working one, one in broken one...

Does your distro use pm-utils, upower, or systemd for suspend/resume
handling?

Dan

Hi!

I wanted to re-test next (4.16.0-rc7-next-20180329), but that one does
not suspend at all.

I normally suspend by pressing power button in MATE, but that action
currently results in machine hanging.

								Pavel


On Mon 2018-03-26 10:33:55, Dan Williams wrote:

On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:

quoted

quoted

quoted

quoted

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a
problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to debug
further.  Before you suspend, run "nmcli gen log level trace" to
turn
on full debug logging, then reproduce the issue, and send a pointer
to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.

Hmm :-)

root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'

What NM version?  'trace' is pretty old (since 1.0 from December 2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it.  Anyway, debug would do.

quoted

root@amd:/data/pavel# nmcli gen log level help
Error: Unknown log level 'help'

nmcli gen help

quoted

root@amd:/data/pavel# nmcli gen log level
Error: value for 'level' argument is required.
root@amd:/data/pavel# nmcli gen log level debug

This should be OK.

quoted

root@amd:/data/pavel# cat /var/log/sys/log

It routes it to whatever the syslog 'daemon' facility logs to (however
that's configured on your system).  Usually /var/log/messages or
/var/log/daemon.log or sometimes your distro configures it to
/var/log/NetworkManager.log.

Or if you're using a systemd-based distro, it would probably be in the
systemd journal so "journalctl -b -u NetworkManager"

quoted

Where do I get the logs? I don't see much in the syslog...

quoted

And.. It seems that it is "every other suspend". One resume results
in
broken network, one in working one, one in broken one...

Does your distro use pm-utils, upower, or systemd for suspend/resume
handling?

Dan

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Mon 2018-03-19 18:33:56, Pavel Machek wrote:

On Mon 2018-03-19 10:40:08, Dan Williams wrote:

quoted

On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims
that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
									
Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Where does the complaint occur?  In the GUI, or with nmcli, or
somewhere else?  Also, what's the output of "nmcli dev" after resume?

In the GUI. I click in place where I'd select access point, and menu
does not show up, telling me that "network is disabled".

Ouch and the bug now crept to mainline.. and it happens on X220,
too. With ethernet, bug is harder to see, because "network is
disabled" and "no network" icon is there, but ethernet still works.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Tue 2018-03-20 21:11:54, Woody Suwalski wrote:

Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
                                   Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Works here OK. Tried ~10 suspends, all restarted OK.
kernel next-20180320
nmcli shows that Wifi always connects OK

Woody

Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
I think that Dan's suspicion is correct - it is a snafu in the PM: trying to
hibernate results in a message:
Failed to hibernate system via logind: There's already a shutdown or sleep
operation in progress.

And ps shows "Ds /lib/systemd/systemd-sleep suspend"...

Problem now seems to be in the mainline.

But no, I don't see systemd-sleep in my process list :-(.

I guess you can't reproduce it easily? I tried bisecting, but while it
happens often enough to make v4.17 hard to use, it does not permit
reliable bisect.

These should be bad according to my notes

b04240a33b99b32cf6fbdf5c943c04e505a0cb07 
 ed80dc19e4dd395c951f745acd1484d61c4cfb20
 52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
 4fc97ef94bbfa185d16b3e44199b7559d0668747
 14ebdb2c814f508936fe178a2abc906a16a3ab48
 639adbeef5ae1bb8eeebbb0cde0b885397bde192

bisection claimed

c16add24522547bf52c189b3c0d1ab6f5c2b4375

is first bad commit, but I'm not sure if I trust that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Mon 2018-03-26 10:33:55, Dan Williams wrote:

On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:

quoted

quoted

quoted

quoted

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a
problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to debug
further.  Before you suspend, run "nmcli gen log level trace" to
turn
on full debug logging, then reproduce the issue, and send a pointer
to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.

Hmm :-)

root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'

What NM version?  'trace' is pretty old (since 1.0 from December 2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it.  Anyway, debug would do.

Hmm.

pavel@duo:~$ /usr/sbin/NetworkManager --version
You must be root to run NetworkManager!
pavel@duo:~$ sudo /usr/sbin/NetworkManager --version
0.9.10.0

So I set the log level, but I still don't see much in the log:

Apr 14 18:14:29 duo dbus[3009]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Apr 14 18:14:29 duo nm-dispatcher: Dispatching action 'down' for wlan1
Apr 14 18:14:29 duo systemd[1]: Started Network Manager Script
Dispatcher Service.
Apr 14 18:14:29 duo systemd-sleep[6853]: Suspending system...
Apr 14 21:27:53 duo systemd[1]: systemd-journald.service watchdog
timeout (limit 1min)!
pavel@duo:~$ date
Sun Apr 15 12:26:32 CEST 2018
pavel@duo:~$

Is it possible that time handling accross suspend changed in v4.17?

I get some weird effects. With display backlight...

quoted

Where do I get the logs? I don't see much in the syslog...

quoted

And.. It seems that it is "every other suspend". One resume results
in
broken network, one in working one, one in broken one...

Does your distro use pm-utils, upower, or systemd for suspend/resume
handling?

upower, I guess:

pavel@duo:/data/l/linux$ ps aux | grep upower
root      3820  0.0  0.1  42848  7984 ?        Ssl  Apr14   0:01
/usr/lib/upower/upowerd

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On Sun, 2018-04-15 at 18:16 +0200, Pavel Machek wrote:

On Mon 2018-03-26 10:33:55, Dan Williams wrote:

quoted

On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:

quoted

quoted

quoted

quoted

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a
problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to
debug
further.  Before you suspend, run "nmcli gen log level trace"
to
turn
on full debug logging, then reproduce the issue, and send a
pointer
to
those logs (scrubbed for anything you consider sensitive) to
the NM
mailing list.

Hmm :-)

root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'

What NM version?  'trace' is pretty old (since 1.0 from December
2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it.  Anyway, debug would do.

Hmm.

pavel@duo:~$ /usr/sbin/NetworkManager --version
You must be root to run NetworkManager!
pavel@duo:~$ sudo /usr/sbin/NetworkManager --version
0.9.10.0

So I set the log level, but I still don't see much in the log:

Apr 14 18:14:29 duo dbus[3009]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Apr 14 18:14:29 duo nm-dispatcher: Dispatching action 'down' for
wlan1
Apr 14 18:14:29 duo systemd[1]: Started Network Manager Script
Dispatcher Service.
Apr 14 18:14:29 duo systemd-sleep[6853]: Suspending system...

I think if systemd really is handling the suspend/resume, you'll need
to make sure NM has systemd suspend/resume handling enabled as well. 
NM 0.9.10 has build-time support for both:

[--with-suspend-resume=upower|systemd]

while later versions also support ConsoleKit2 and elogind.

Any idea what your NM was compiled with?  Though honestly I'm not sure
how all the suspend/resume stuff is supposed to work these days on
different distros that provide the choice between systemd/upower/pm-
utils/CK2/etc.

Dan

Apr 14 21:27:53 duo systemd[1]: systemd-journald.service watchdog
timeout (limit 1min)!
pavel@duo:~$ date
Sun Apr 15 12:26:32 CEST 2018
pavel@duo:~$

Is it possible that time handling accross suspend changed in v4.17?

I get some weird effects. With display backlight...

quoted

quoted

Where do I get the logs? I don't see much in the syslog...
And.. It seems that it is "every other suspend". One resume
results
in
broken network, one in working one, one in broken one...

Does your distro use pm-utils, upower, or systemd for
suspend/resume
handling?

upower, I guess:

pavel@duo:/data/l/linux$ ps aux | grep upower
root      3820  0.0  0.1  42848  7984 ?        Ssl  Apr14   0:01
/usr/lib/upower/upowerd

									
Pavel

Hi!
On Mon 2018-03-26 10:33:55, Dan Williams wrote:

On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:

quoted

quoted

quoted

quoted

Ok, what does 'nmcli dev' and 'nmcli radio' show?

Broken state.

pavel@amd:~$ nmcli dev
DEVICE  TYPE      STATE        CONNECTION
eth1    ethernet  unavailable  --
lo      loopback  unmanaged    --
wlan0   wifi      unmanaged    --

If the state is "unmanaged" on resume, that would indicate a
problem
with sleep/wake and likely not a kernel network device issue.

We should probably move this discussion to the NM lists to debug
further.  Before you suspend, run "nmcli gen log level trace" to
turn
on full debug logging, then reproduce the issue, and send a pointer
to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.

Hmm :-)

root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'

What NM version?  'trace' is pretty old (since 1.0 from December 2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it.  Anyway, debug would do.

...

Hmm. I also noticed now screen saver kicks in _right after I resume
the machine_. That did not use to be the case (and is a bit annoying
on its own).

Do we have any changes with time across suspend/resume in v4.17?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek wrote:

On Tue 2018-03-20 21:11:54, Woody Suwalski wrote:

quoted

Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:

quoted

Pavel Machek wrote:

quoted

Hi!

With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.

Any ideas? Does it work for you?
                                     Pavel

Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.

Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.

Works here OK. Tried ~10 suspends, all restarted OK.
kernel next-20180320
nmcli shows that Wifi always connects OK

Woody

Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
I think that Dan's suspicion is correct - it is a snafu in the PM: trying to
hibernate results in a message:
Failed to hibernate system via logind: There's already a shutdown or sleep
operation in progress.

And ps shows "Ds /lib/systemd/systemd-sleep suspend"...

Problem now seems to be in the mainline.

But no, I don't see systemd-sleep in my process list :-(.

I guess you can't reproduce it easily? I tried bisecting, but while it
happens often enough to make v4.17 hard to use, it does not permit
reliable bisect.

These should be bad according to my notes

b04240a33b99b32cf6fbdf5c943c04e505a0cb07
  ed80dc19e4dd395c951f745acd1484d61c4cfb20
  52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
  4fc97ef94bbfa185d16b3e44199b7559d0668747
  14ebdb2c814f508936fe178a2abc906a16a3ab48
  639adbeef5ae1bb8eeebbb0cde0b885397bde192

bisection claimed

c16add24522547bf52c189b3c0d1ab6f5c2b4375

is first bad commit, but I'm not sure if I trust that.
									Pavel

It has not happen on any of my systems in the last month. Good, but bad for getting more info :-(

Woody

Hi!

quoted

I guess you can't reproduce it easily? I tried bisecting, but while it
happens often enough to make v4.17 hard to use, it does not permit
reliable bisect.

These should be bad according to my notes

b04240a33b99b32cf6fbdf5c943c04e505a0cb07
 ed80dc19e4dd395c951f745acd1484d61c4cfb20
 52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
 4fc97ef94bbfa185d16b3e44199b7559d0668747
 14ebdb2c814f508936fe178a2abc906a16a3ab48
 639adbeef5ae1bb8eeebbb0cde0b885397bde192

bisection claimed

c16add24522547bf52c189b3c0d1ab6f5c2b4375

is first bad commit, but I'm not sure if I trust that.
								Pavel

It has not happen on any of my systems in the last month. Good, but bad for
getting more info :-(

My current theory is that it only happens if you suspend your machine
for > ten minutes, or something like that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html