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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Apr 2018 10:03:59 -0500
From:   Dan Williams <dcbw@...hat.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Woody Suwalski <terraluna977@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        kernel list <linux-kernel@...r.kernel.org>,
        Linux-pm mailing list <linux-pm@...r.kernel.org>,
        Netdev list <netdev@...r.kernel.org>
Subject: Re: linux-next on x60: network manager often complains "network is
 disabled" after resume

On Sun, 2018-04-15 at 18:16 +0200, Pavel Machek wrote:
> On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> > On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > > 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...
> 
> > > 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